MONDAY, July 23rd, 2007 - 13:00 - 15:00 ----------------------------------- CHAIRS: Danny McPherson & Stewart Bryant SCRIBE: Matthew Bocci WG Status and Update - Chairs ----------------------------- Two new RFCs - cell transport and wildcard. RFC Eds queue - AII aggregation. Waiting for L2VPN signalling, which is waiting for segmented PW draft, which is waiting for MS-PW requirements. TDMoIP and CESoPSN are waiting for VCCV. draft-malis (SonetoMPLS) is with IESG as independent submission - will go as historic RFC. PW type 8 and 10 both point to CEM - they should point to CEP and CEM. MIBS in last call. Work in progress: - Congestion framework. Alison Mankin is transport area advisor for this. - FC encap. Comments received from transport area. Authors are currently revising the draft. - MPLS transport - discuss on this agenda later MS-PW architecture is waiting on getting requirements through. oam-msg-map is being revised and will then be ready for last call. Segmented-pw and dynamic-ms-pw are work in progress. Need WG drafts on PW protection and restoration. Possible new items: - MPLS PW - Multipoint PWs Pseudowire Virtual Circuit Connectivity Verification (VCCV) A Control Channel for Pseudowires - Tom Nadeau (tnadeau@cisco.com) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-14.txt --------------------------------------------------------------- This received extensive IESG review. Made significant changes as a result of this: - BFD CC and CV types have been removed. These are in another draft. - Improved readability. - Many editorial changes. - Improved security section. Next steps: need to clear 2 remaining DISCUSS states, to do with congestion. Need one more AD to approve before moving forward. We hope to do this in the next month or so, and will publish v15 afterwards. Stewart: needs WG last call because of the scale of the changes. Don O'Connor: What is the new draft? Tom: will take BFD CV and CC components verbatim. Stewart: The comment was that there were lots of things thrown into one. With BFD, it is a new mechanism so is a better compartmentalism. No technical changes. George Swallow: BFD still hasn't moved very far, so this breaks the deadlock. Stewart: this way, no normative references that are not already RFCs. Preferential Forwarding Status Bit Definition - Mustapha Aissaoui (mustapha.aissaoui@alcatel-lucent.co.uk) http://www.ietf.org/internet-drafts/draft-muley-dutta-pwe3-redundancy-bit-01.txt -------------------------------------------------------------------------------- New revision. Add a new contributor. Expanded on motivation of status bit. Added separate definition of active/standby PW states for independent mode etc Enforced rule that endpoint MUST not forward over PW in standby mode Removed the option to send the PW not forwarding status bit could not unblock PW. Added applicability and backward compatibility. Removed reference to LDP and point to RFC4447 for security. Active state is where PW label are exchanged between two endpoints, and status bits exchanged between endpoints indicate the PW is in active state. Similarly in standby state. Interop with existing implementations: - Mechanisms are OPTIONAL and - Must negotiate use of status TLV - PE implementation could support status, but not this bit. Procedures in this draft will not be used. Next steps: Could change to 2 bits: - request to switch - view of the state at far end Would like feedback further WG feedback. Don O'Connor: Any plans for mechanics of protection switching? Or is this for companion draft? Any plans for revertive mode? Mustapha: Need to discuss this, but don't want to make it too complicated. Don't plan to go to a very complex mechanism, but here may be a value in it. Danny: will ask if this should be a WG draft on the mailing list. MS-PW Requirements - Luca Martini (lmartini@cisco.com) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-05.txt ----------------------------------------------------------------------------- In IESG review. Received several discusses. Some are resolved. - Points about RFC 3985 still applying. Congestion mitigation does not add anything, but makes it clear it is more of a requirement. - Clarification of meaning of OAM Dan still has a requirement that this should be provisioned by CLI. This is a problem e.g some might use GUI. This is a protocol requirements draft. This point is still under discussion. Resolved comment about mandatory to implement PSN security. More security comments still need to be resolved. Dynamic Placement of Multi Segment Pseudo Wires - Luca Martini (lmartini@cisco.com) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-05.txt ------------------------------------------------------------------------ Added text to explain the procedure if PW label mapping is immediately released. Added a procedure to handle if AII unreachable case. Incorporated comments from WG. Allocated BGP SAFI, and new LDP TLV/status code points. Would prefer if people mail comments to the list, rather than personally. Luca would like to use early allocation process. Would need to come from chair of IDR for BGP AFI/SAFI. Stewart - we are working through the process of getting allocation. Has to come from IDR. Alison Mankin - This is about the LDP question. You said you could not make a requirement on security. But this is about inter-domain cases, and is especially for users of the protocol. Yakov Rekhter - There is a document in L2VPN called L2VPN signalling. That describes how to place a MS-PW. Can you use them together? Luca - that is about provisioning using BGP. Cannot use them together, but they can coexist. Yakov Rekhter - would lie to spell this out explicitly Yakov Rekhter - There is a different NLRI format in Eric's document. Luca - that is an addressing plan for a service. This is a PW. Eric's document optimised for a service. This document is meant to aggregate the reachability so if you don't need to advertise for every PW. This addressing scheme allows optimization. Yakov Rekhter - just to clarify that the two should not be used together for the same AC. Vach Kompella - Why can they not be used together? One is doing routing and one is doing discovery. Yakov Rekhter - not for the same set of ACs Rahul Aggarwal - Appears that the only difference is that... Stewart - Take to the list and come up with definitive text on why they are going to be the same or not 802.1ah Pseudowire - Luca Martini (lmartini@cisco.com) http://www.ietf.org/internet-drafts/draft-martini-pwe3-802.1ah-pw-00.txt ------------------------------------------------------------------------ Explains the new PW type. This binds port and ISID. E.g. similar to the VLAN type we have today. The ISID is the service identifier. Keep the single lookup architecture that is the basis of all PWs. The label uniquely identifies what the egress port is, and what the header rewriting procedure is. Draft uses RFC4448 as a template. Need to incorporate some comments e.g. congestion handling text and is CW optional Florin Balus - Can you clarify that you are using this for ITAG interfaces? Luca - Yes Yakov Stein - The title .1ah does not properly describe this. This does not cover BVID. So perhaps you should put in abstract or correct the title. Ali Sajassi - The draft is not the name of the PW. The PW is ITAG PW. If the interface is ITAG it is ACs, but if it is VPLS, you are talking about the internal of the box. Yakov Stein - Since ah is already a client of Ethernet, and so is this, maybe a diagram to explain why you really need this. Danny - Will likely see WG doc request on the mailing list. Setup and Manage PBB-based Tunnels with PWE3 Mechanism - Ping Pan (ppan@hammerheadsystems.com) http://www.ietf.org/internet-drafts/draft-pan-pwe3-pbb-tunnels-00.txt --------------------------------------------------------------------- Not a debate of MPLS vs. PBT. This is addressing a particular problem. The problem is that there are access VLAN networks interconnected by a MAC-in- MAC network. Need to know how to setup and manage VLAN circuits. How to extend Ethernet to the core? For operational reasons, may not use MPLS at the edge. This is a migration step. Ways to setup the edge-to-edge tunnels - Existing practice: static configuration - Other proposals dynamic signalling proposals - Outside the scope Proposes to use LDP to setup the PBB tunnel Shows the header. Encode MAC-in-MAC header in AII and AGI Asks for new AII type Ali Sajassi: Debate is whether this draft is needed. There are inaccuracies in the draft about PBB. Ping: Are we trying to set up tunnel or PW? The PW is inside the tunnel. We do not touch the tunnel. Ali Sajassi: You do not need to tell the PE the MAC address. It does this though ARP. If you are trying to set up a .1ah PW, there is already a draft for this. Adrian Farrel - don't see any mention of Internet protocols in this draft Kireeti Kompella - PWE3 charter says over IETF PSNs. PBB is not an IETF PSN. Stewart - This would definitely need a charter change. We need to debate if we should be doing this work or not. Ping Pan - Let's try to work out if this is useful. ? - Need to signal a tunnel per service instance. You will also get P2MP tunnels. PBB would give you P2MP tunnels Luca Martini - Suggest reading the LDP RFC. No FEC for what you have written. There is also no MPLS here, so what is this doing here? Ping - just using the signalling protocol Loa Andersson - need to make it clear that don't want to say this is not a problem. But we started the PWE3 working group to set up PWs over the Internet. It is a gross charter violation. Yakov Stein - this is the same issue as the GELs BoF. Found that we needed to liaise to the IEEE. Could apply what happened to gels and look to CCAMP. ? - Problem in GELS was not to define a new data plane. Ping Pan - we should not make a religion out of this. We are engineers and have a real problem to solve in Ethernet. Stewart - we are concerned about other SDOs rewriting our protocols. We should not be doing this without IEEE consensus. Mark Townsley - Need to think about what the full implications are. This is why we go through the re-chartering process. Danny - Please comment on this on the mailing list. PTP over MPLS - Roh Cohen (ronc@resolutenetworks.com) http://www.ietf.org/internet-drafts/draft-ronc-ptp-mpls-00.txt -------------------------------------------------------------- PTP is protocol delivering time synchronisation from master to slaves. Forms a hierarchy of master and slaves Signalling messages exchanged between clock for negotiation, setup, etc. Entities: PTP clock, Boundary clock, transparent clocks Shows sync and delay req formats. PTP defined for Ethernet (802.1as...) and IP Proposes to take PTP and map directly over a PW. Shows detail of the encapsulation. Scope is limited to P2P LSPs. Shows model with transparent clocks. Model is similar to MS-PWs, except S-PE not only switches the labels, but there is native service processing. Communications path maps into a set of LSPs. PTP domains are sent on different PTP LSPs. Suggests using LDP for setting up bidirectional LSPs, and using PTP PW types - End to end - Peer to peer Open issues: - Traffic engineering - Use of RSVP-TE for tunnel LSP - Automatic protection switching - FEC collision in P2MP LSPs PWE3 is right place to advance this work - right place to progress non-IP over MPLS Add to PWE3 and add to TICTOC if chartered. Yakov Stein - Lots of good points, but a bit uncomfortable using PW for this. PWs are for carrying data. You are also saying you set up a MS-PW, with a stitching point which has an NSP in it. Ron - might be easier not to use the stitching model. Instead have two separate PWs set up between PEs containing transparent Yakov Stein - the right place to do this is TICTOC Ron - if TICTOC is chartered, then it is possible that this could move there. Not proposing anything in way of handling the timing. Stewart - this needs a charter change. Logically, TICTOC is where to do it. Should this WG act as a caretaker until a decision is made? This is only a first cut and needs to design work before we can answer this. Yakov Stein - Not just a pure data encap issue, which is why I am not sure expertise is here. Mark Townsley - agrees that this does seem significant enough to PWE3 to require something to be done. But let's focus efforts on TICTOC so this work does not force itself in PWE3. Stewart - should take this off line. T-MPLS - Italo Busi (italo.busi@alcatel-lucent.it) --------------------------------------------------- Shows a slide summarizing status of T-MPLS work in ITU-T. Forwarding component using RFC3031/3032 etc - PHP switched off, no merging, no ECMP Label space is per-platform/interface assignment with downstream, and context specific with upstream label assignment for P2MP T-MPLS not only Ethernet PW over a MPLS PSN - there are proposals to add support for ATM etc using PWE3 RFCs and data plane Good opportunity to work together on this. There are proposals on the interoperability with IP/MPLS. Good opportunity to work together on this. Differences are with OAM (no IP forwarding) - T-MPLS OAM identified using label 14 assigned by IETF to ITU-T protection is data plane driven only, based on T-MPLS OAM Control plane - option to work without control plane. This is the current standard. - Work starting on T-MPLS CP based on GMPLS Good opportunity to work together on this. Monique Morrow - Concern is reuse of an ethertype already assigned to IETF. Reuse of this is a concern. Also, what is an MPLS level? Italo - T-MPLS speaks at IETF MPLS level Monique Morrow - Label 14 was designed for Y.1711, but T-MPLS is not using this. Italo - T-MPLS OAM is an extension of this. Monique - but this is not Y.1711 George Swallow - is there any technical benefit from using the same ethertype? Italo - same data encapsulation and forwarding plane George Swallow - when a label comes into a box, it has a set of procedures for what to do. You are changing the label allocation and semantic of label 14. So you should use a different Ethertype. Yakov Rekhter - you talk about interoperability. I would like to understand if this includes OAM and control plane. Italo Busi - not all of the details have been worked out. Control plane is the most complex one. Ross Callon - Very nervous about how it is going to work when it uses a different label management scheme. Loa Andersson - Are there any real technical benefits from using the same ethertype? Italo - this is an MPLS packet, so we decided to use the same ethertype because we are Loa Andersson - so you cannot give one. Italo - it is a profile of MPLS data plane. Andy Malis - so I don't see a downside from using a separate ethertype. Ross Callon - you said it is a profile of MPLS, but it uses different label allocation, OAM ... etc Stewart - Can I assert that if the group owning the protocol does not agree, then it is not a profile. Ben Niven-Jenkins - It is a profile at the data plane, but operating a network is much more than that. Interworking this will be a complete nightmare. Nurit - you can use different OAM mechanisms for the same ethertype, so this argument is not valid. Mark Townsley - agrees with the gentleman from BT that this is a nightmare. Your story is not consistent with what you are saying at ITU about interworking. T-MPLS Report - Stewart Bryant (stbryant@cisco.com) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-00.txt https://datatracker.ietf.org/liaison/345/ https://datatracker.ietf.org/liaison/344/ ----------------------------------------- Presents the key changes to the draft and responses form ITU-T. Noted that key requirements can be addressed by PWE3 Liaison back Notes that 2 service providers support requirements Goes through responses one by one. Does any of this feedback indicate we should make any technical changes to PWE3 MPLS transport draft? Do we last call it? Do we want to so more work? Monique Morrow - Should last call it Tom Nadeau - clear they don't want to provide constructive feedback, so should last call it. Ben Niven-Jenkins - last call it. Yakov Rekhter - last call it Danny - Pretty clear we should last call it.