MONDAY, December 3rd, 2007 – 15:20 - 17:20 ----------------------------------- CHAIRS: Danny McPherson & Stewart Bryant SCRIBES: Matthew Bocci and Yaakov Stein JABBER: Yaakov Stein 15 mins WG Status and Update - Chairs 17 RFCs published. AII aggregate is new : RFC 5003 3 in RFC eds queue MS-PW requirements: new draft has been uploaded Summarises work in progress OAM message map: needs updating. Monique Morrow: waiting for VCCV. Next in queue TDM control extensions is ready for proto MIBs: a couple have expired. Will progress these and have had some feedback. Looking good. PW protection and restoration needs to be adopted. Possible New items: MPLS PW Multipoint PWs T-MPLS ad hoc committee outputs Others? E.g. OSPF extensions. Need to decide if this should be done in OSPF or PWE3, if we decide to adopt it. VCCV-BFD – Tom Nadeau (tom.nadeau@bt.com) http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00 ----------------------------------------------------------------- Giles Heron standing in for Tom. VCCV draft was split to simplify the base spec. As few areas where we need refinement: - 4 different BFD CV types defined - how does a PE select among BFD modes? - text says should use LDP status if using the control plane. - How to decide if you want UDP/IP headers or not. Where to go from here: already a WG draft because it was split off out of a WG draft. Currently held up by base BFD drafts. Need WG input ASAP. Danny: Tom wants to wrap up within a couple of months. PW Redundancy – Marc Lasserre (marc.lasserre@alcatel-lucent.com) http://tools.ietf.org/wg/pwe3/draft-muley-dutta-pwe3-redundancy- bit-02.txt http://tools.ietf.org/wg/pwe3/draft-muley-pwe3-pw-redundancy- 02.txt ------------------------------------------------------------------ --------- Matthew Bocci standing in for Marc Lasserre standing in for Mustapha. Shows a slide explaining "request switchover". T-PE1 communicating with T-PE2 with 3 S-PEs in between Draft muley up to version 02 Authors requesting to move to WG status Dave McDyson: Proposes requirements be settled first. Also requests cross-referencing other drafts, and explaining terminology. Stewart: asks what alignment is required Dave McDyson: IEEE protection, and possibly ITU Matthew: That is part of requirements draft Dave McDyson: The solution seems to rely on correct configuration. Automatic identification of master and slave would be nice. Danny: Are you volunteering to help ? Dave McDyson: yes Dave says he is happy that Luca is now working on this draft as well Luca Martini (via Jabber): Hey ! , this is a very different document since the time I made that statement ! Danny: will ask on the list. Pseudowire Emulation MPLS PSN Congestion Status Bit – Matthew Bocci (matthew.bocci@alcatel.lucent.co.uk) http://tools.ietf.org/wg/pwe3/draft-bocci-martini-pwe3-psn- congestion-bit-00.txt ------------------------------------------------------------------ ------------- Matthew: PWE3 needs to provide congestion handling mechanism Talks about congestion of underlying PSN, PW needs to be TCP friendly This new draft talks about how egress PE signals ingress PE on congestion detection. Control plane mechanism: reliable, scalable, avoids using scarce bits in PW header. Egress PE2 detects congestion by packet loss/VCCV/ECN It sends congestion status back to PE1, which applies control Second case - MS-PW T-PE2 sends message to S-PE which forwards to T-PE1. S-PE can also apply congestion control locally, or originate the status message. When congestion ceases - egress PE sends PW status with status bit cleared Need to avoid flapping (when resume it causes congestion again). Need to work details out. Matthew asks for feedback to the list, and to move to WG draft Stewart: need feedback from TSV area since they are the ones that want it. Mark Townsley: Have you asked them? Stewart - not yet, will now Mark Townsley: In MS-PW case, can we get a broadcast storm? Matthew: Limited to one per T-PE. Stewart: Only at the start Mark Townsley: Let the transport people work on this Himanshu Shah: we published the shah-pwe3-pw-qos-signalling draft and did a presentation back in 2005. This draft proposes a better mechanism for exchanging capability, exchanging more precise QOS information in LM message, exchanging updated QOS information in LDP Status messages from egress PE to ingress PE for initial traffic shaping and throttling traffic flow. We believe this is a better/finer mechanism than congestion bit based (coarse) mechanism. We intend to revive this draft to address the congestion issue. Matthew: It might be that only the ingress PE knows if the traffic is elastic Luca Martini (via Jabber): The mitigation function is PW technology specific Rob ?: do you indicate to source to increase policing? Matthew: yes Luca Martini (via Jabber) it varies from shutting down a pw ( TDM ) to applying a policer. Danny: need feedback, make sure aligned with TSV (Allison) Load Balancing Fat MPLS Pseudowires - Joerg Kuechemann (Joerg.Kuechemann@telekom.de) http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00 ------------------------------------------------------------------ ---------- Ulrich presents.: Transport label is chosen by a hash algorithm, but the PW always takes the same route. This leads to imbalance Options: - DPI would need lots of computing power in P and PEs Next try was PW label range ("label block"), whereby several PW labels mapped to AC Shows diagram with 2 PWs (could be more, e.g. 16) Hash on PW label Shows format - header has ethernet + IP header + PW label, hashing to get transport label Final solution - new label after PW label, finer granularity Primary hashing based on load balancing label Need to pop 2 labels at PE In either case need new TLVs for signalling Conclusion - need at least one solution to this problem Label range is easy to implement, lad balancing label solution is better since more generic Since not interoperable, should we choose one, or put both in one draft? Stewart: since draft came out other operators have expressed interest Need to compare possible solutions Ali Sajassi: have you considered OAM issues? Stewart: Discussed with Luca, majority interest is for IP Operators expressed interest - DT and others on list in last 2 days) Giles Heron: customer's IGP is easy, SP IGP harder Stewart: SP should self repair Kireeti Kompella: answering a few questions. Important problem, but may not need a draft. Either solution can live with LSP ping as OAM Stewart: authors want input from list. Giles Heron: only a subset is being handled here. Stewart: IP case is the most urgent George Swallow: need to get OAM considerations out on the table before choosing an approach. Giles Heron: need to document which scenarios we are addressing. Stewart: need to send requirements to the list. The IP case is certainly the most urgent. Giles Heron: but perhaps IP with tunnels hiding header is the most urgent OSPF Extensions for Dynamic Multi-segment Pseudo Wires – Andrew Dolganow (andrew.dolganow@alcatel-lucent.com) http://tools.ietf.org/wg/pwe3/draft-dolganow-pwe3-ospf-ms-pw-ext- 01.txt ------------------------------------------------------------------ -------- Presented to OSPF in Prague. New coauthors added. Comments incorporated into new version. Changes in version 1.0: Priority given to consensus parts of original draft. - advertise AII - router does not need T-LDP or Tunnel - Opaque LSA mechanism used - PW switching LSAs carry AIIs attached at T-PEs: configuration, advertisement, interaction with EGPs e.g.BGP Full alignment with dynamic placement of MS-PWs draft Shows an example of how it works. Next steps: work closely with OSPF and adopt as a PWE3 WG draft Create an IS-IS version Danny: need to determine if we want to do this first and then decide where to do it. Stewart: is there any plan to include TE metrics? Andrew: could use IGP first, then could add more later Stewart: need to make sure that do not overload routing protocols. Other work needs to be done first to check this. Andrew: This was already discussed in OSPF Stewart: routing groups must make the call as to whether this is safe for routing. Rahul: You are violating architecture as you are advertising customer state Luca Martini (via Jabber): only intended for aggregation, and operators today put customer state in the IGP Ali Sajassi: Need this in the IGP because the low cost T-PEs in the aggregation do not run BGP Alex Zinin: Separation of resources: remember that different LSP fragments can be advertised separately in IS-IS. Regarding BGP and OSPF, obviously requirements for non-BGP solutions. Danny: how many people see interest in this: a small number of hands Ali Sajassi: Need some additional discussion with respect to how with convey this information. Need to still carry some info in P- nodes. Do we need to modify PW architecture for this? P-nodes are no longer completely transparent. Stewart: it is the ABRs ? Need to discuss this off-line. Luca Martini (via Jabber): OSPF is just a transport protocol for the external routes. P nodes install no state ! Danny: take this to the mailing list as to whether we should do this or not. Dynamic Update of PW parameters (v00) – Frederic Jounay (frederic.jounay@orange-ftgroup.com) - http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynamic-pw- update-00.txt ------------------------------------------------------------------ --------- Need this for mobile backhaul for voice services – TDM PWs. Need to do this update without impacting customers. Scenarios: - setup a new PW. New FEC-> new PW label. Static switching from the old to the new PW. - Scenario 2: PW update – retain the existing FEC. New label mapping message with dynamic PW update Draft defines a generic solution. Presents the CESoPSN parameters that are relevant. Configured: number of time slots: N Signalled: P N and P must be included in the label-mapping message Proposes PW update TLV. Use it increase or decrease PW capacity. Illustrates how this works for a CESoPSN PW. Next steps: add a section that describes the PW label removal from the LFIB Describe the MS-PW approach Solicit comments. Stewart: do we need a requirements document? This is a change in the way PWs work as they were previously static for life. Hamid Ould-Brahim: reminds me of work we did a while ago with Himanshu. Why is this coming back? Frederic: this is a change in interface parameters, so this couldn’t be done before. Hamid Ould-Brahim: you are reprogramming the data plane. You are doing a new PW in some sense. Stewart: can we start by gathering requirements? Nitin Bahadur: Still not convinced that need anything new. Danny: Need to work on a requirements document. P2MP PW Requirements v01 - Frederic Jounay (frederic.jounay@orange- ftgroup.com) http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-p2mp-pw- requirements-01 ------------------------------------------------------------------ ---------- Illustrates changes since last version. Clarified the definition wording. P2MP PW provides a unidirectional service. Introduces Virtual Private P2MP service (VPMS). Shows P2MP SS-PW reference model. Removed some text: parts referring to VPLS, source/leaf initiated setup, pats referring to technical spec. Replaced controversial text. Next steps: solicit comments and adopt as WG draft Stewart: who is interested in adding this to the charter? Some support Matthew: need to clarify what the difference is between this and multicast services in L2VPN Stewart: Question for the ADs PMP PW Signaling and Auto-Discovery in L2VPNs - Rahul Aggarwal(rahul@juniper.net) http://tools.ietf.org/wg/l2vpn/draft-raggarwa-l2vpn-p2mp-pw-00.txt ------------------------------------------------------------------ Describes what a P2MP PW is. P2MP PWs enable a L2VPN to provide a virtual private P2MP service. A L2VPN offering VPMS referred to as a L2 Multicast VPN Explains the relationship between sender sites and receiver sites. Describes BGP auto-discovery using BGP, and BPLS MCAST Uses procedures from these drafts Signaling procedures use upstream assigned labels using draft-ietf- l2VPN-VPLS-mcast Inter-AS options are supported by P2MP PWs. A multi-segment P2MP PW is equivalent to an inter-AS tree Stewart: need to have a definition of the work area. Need to have clear blue water between us an L2VPN. Ali: this is my comment exactly. 2 things: auto-discovery and signalling. Both of these are already done in L2VPN. Stewart: need to see if this should be done here or not. Ali: inter-AS requirement needs to be better cooked. T-MPLS Update – Stewart bryant (stbryant@cisco.com) --------------------------------------------------- At last IETF, concerns were raised about redefinition of PWE3 and MPLS design by T-MPLS. Many discussions and a liaison sent to ITU-T about this. Concern covered MPLS ethertypes, and other architecturally unsound issues. Liaison addressed issues of separation. Options presented: - work together. IETF preferred solution - state that IETF MPLKS and T-MPLS are different, and ITU-T should have complete code point separation. Not preferred solution. ITU management referred liaison to four ITU-T groups Stuttgart proposal: - codepoint separation recommended to be rejected - Compatible and consistent design - Sole MPLS design expertise in IETF - Transport network expertise in the ITU-T - Lists domains Proposed joint working team. Ben Niven-Jenkins: doesn’t seem very realistic to bring this work into the IETF. What is actually going to happen when inconsistencies are found? Stewart, the agreement is that where there is a conflict, ITU recommendations will be modified to align with IETF architecture Normative IETF references should be used in the case on any discrepancy. SG11 and 15 have endorsed the recommendation. SG13 will meet in January to discuss. However, G8113 and G.8114 may be consented at this meeting, unless one country or two sector members object. Concerns: - MPLS label 14 - Semantics of MPLS EXP and TTL bits, and new P-router behaviour - Changes to label 14 need action through the IETF - ITU SG15 also accepted a proposal to use label 14 as an IP and management messaging channel. Interim IETF work: small IAB ad-hoc group formed to identify inconsistencies and the IETF decisions to be revisited. Giles Heron: what happens when joint team meets and one side says use BFD, and the other sides uses G.8114? I can see the whole thing falling apart Stewart: that depends on the two management teams Hamid Ould-Brahim: you mentioned changes to MPLS, but you did not mention PWE3 work? Also, we already have a draft in PWE3 that addresses this topic and is based on ITU-T T-MPLS requirements (draft-ietf-pwe3-mpls-transport-01). What's new need to be done besides from what we already have in this draft? Need to consider this draft as input to T-MPLS design team mentioned. Stewart: Yes, we have a WG draft that addresses requirements and needs some more BFD work done. Then it will come back to this group Italo Busi: a couple of comments. - OAM work discussed, and straddles both groups. We need to decide how to proceed. Have not agreed 8114 is going to be used for both domains. Agree that need to make sure that 8114 does not break the internet domain. - Need to clarify what are the problems and some proposals to fix the problems. - Management channel was just a contribution, and there is plenty of time to change this. Prepared to work with them. Need to come with a better solution. Stewart: chair said they were doing nothing that is not allowed by G.8114 Mark Townsley: Tired of T-MPLS and MPLS operating in separate domains. Then reason why the IESG/IAB sent a liaison was because of potential harm. Either get on a different Ethertype, or bring it into the IETF standards process. Kiretti Kompella: echoes Ben’s statement. Had this sort of agreement in CCAMP before. Monique Morrow: have had a plethora of liaisons sent. G.8113/G.8114, they are still at AAP, and that means the comments have not been resolved. The IETF should send a stronger liaison statement to the ITU-T Chris Liljenstolpe: No matter what we say here, we all know that these will end up on the other end of the same link. Italo Busi: Understands concern about G.8114 mechanisms, but does not understand concerns about requirements Monique Morrow: refer to Cisco comments on this. Danny – take it to the mailing list Eve Varma: we just rehash over and over when we talk about generalities. MEETING CLOSES