********************************************************************** PWE3 - MONDAY, March 28, 2011 0900-1130 - Congress Hall I ********************************************************************** Chairs: Matthew Bocci and Andy Malis Secretary: David Sinicrope (x=No slides as of 08:45 28Mar2011) 15 min - Agenda bash, WG Agenda and Status - Andy Malis and Matthew Bocci See slides Andy opened the meeting Matthew gave the WG status Yaakov Stein - on FC draft one open issue regarding code points. Resolved, Stewart as expert will approve and will be defined in IANA sections of that draft. Yaakov Stein - OAM message mapping draft. There was a discuss with Adrian, all points have been resolved. One point that is not a Discuss needs to be resolved with the community. For Ethernet message mapping, needs review. One point that relied on message mapping draft older version. Luca Martini - on dynamic MS pw draft - have received comments on make before break. The comments will be addressed and the draft reissued. Matthew - we should work on getting this draft in a state before the next IETF to send to last call. Stewart - on fiber channel waiting for a new version from authors. There are some old code points lying around that need to be tidied up. Matthew - Need to get more reviewers on ethernet message mapping draft Matthew - pwe3 static pw status is it ready for last call Luca - it is getting close to last call, perhaps after this meeting Matthew - draft jin should probably be polled to become a WG draft. Nick will go over VCCV Survey results first. 20 min - Control Word Implementation Survey Results - Nick DelRegno http://tools.ietf.org/html/draft-delregno-pw-vccv-impl-survey-results Nick presented the survey results. Wanted to keep survey annonymous so no names listed in results. Did not ask about BFD in the original survey. Will be asking about BFD separately. Already started and Nick will be getting responses. 17 participants so good breadth of answers and good geographic diversity. By far the encapsulations used are ethernet tagged and raw mode. Yaakov Stein - there are few anomilous results. Is there a way to get back and ensure that the respondents understood N:1 mode where N=1 and 1:1 mode? Nick - yes, possible. The 2nd version of the results contain the actual responses. There are some inconsistencies in the responses. How much time to we spend cleaning up responses? Left to WG to determine response clean up and any follow up needed. Q4 Slide Luca - inconsistency between respondents saying they have ATM SDU mode and then number of such PWs = 0 Q5 Slide Luca - same number between those using CW and those not, would be expected. Nick - didn't expect 8 to be as high Q6 Slide Nick - difference between where CW was supported and where it is being used. 10 min - Mandatory Features of Virtual Circuit Connectivity Verification Implementations - Nick DelRegno http://tools.ietf.org/html/draft-delregno-pwe3-vccv-mandatory-features Nick presented slides (same presentation used for this draft and mandatory control word draft) Asked to adopt as WG draft - has been on hold waiting on survey results Andy asked for hum on whether it should be WG draft - inconclusive, will take to the list Loa - Is it reasonable to look at the PW types that showed up as 0s and discontinue work? Andy - need to look at these when the RFCs go to proposed standard. Would be good to bring some to full standard, e.g., Ethernet. For lesser used they may stay at proposed standard Luca - based on experience on LDP 3036-5036 the WG should understand you won't change what is there. You won't be rewriting and fixing to whatever you want. This is not how the process works going from proposed to standard. Just remove what wasn't implemented. Himanshu - What is the goal for this work? A BCP would be appropriate for the survey work. Andy - agree. Note the discussion on the main IETF list to go from the current three levels to two standardization levels. 10 min - Mandatory Use of Control Word for PWE3 Encapsulations - Nick DelRegno http://tools.ietf.org/html/draft-delregno-pwe3-mandatory-control-word Nick presented. Introduced in Beijing. Point made that you can't go back and change what is out there. Asked to make a WG item. Yaakov Stein - problem is not with N:1 ATM, but rather with Ethernet. What does it mean to make it mandatory? What is being proposed? Nick - goal of draft is to make support of CW mandatory. Can choose whether or not to use it, but must be supported. George - without commenting on good or bad, get closer to achieving what you want is non-use of CW is deprecated vs saying CW is mandatory. Curtis - Is deployment or support mandatory. Nick - deployment optional, must be supported in implementaiton Luca - WG can agree that any new PWs oging forward must have CW mandatory. If trying to change what done in the past, then survey shows wide deployment of implementaitons that don't have it. Can't go back and change those implementaitons and deployments. Can mandate in RFC what people deploy. Survey result was 50-50% there is a split that say they want it vs. not. Himanshu - agree with Luca, many implementaitons out there that don't support CW. Too late in the game to make it mandatory. Can make it a BCP, but can't really mandate the CW. Nick - to make it mandatory wold need it to be a new RFC Curtis - If we just make a new RFC and make CW mandatory, doesn't effect old RFC or implementaitons of old RFC. However gives SPs a new RFC to point to for requirements. Yaakov: don't understand if new RFC obsoletes old RFC how woudl this work? Curtis: New RFC just gives SPs something additonal doesn't change old RFC Rob: Draft says SHOULD which is different from MUST. Nick will check draft 10 min - A Unified Control Channel for Pseudowires - Luca Martini for Tom Nadeau http://tools.ietf.org/html/draft-nadeau-pwe3-vccv-2 Luca presented. Rob Redicent? - how is this unifying? WG just discussd making CW mandatory, not this is saying if you don't use CW... how is this unifying seems just a different way to handle same thing. Luca - Using the GAL is handled in hardware. CW is more complex to parse some hardware may not do this. Rob - Still seems not to be unifying? This is inconsistent with the proposal to put GAL at bottom of stack. Sasha - how is this consistent with 6073 which makes Type 3 mandatory for MS PWs? How many RFCs must be upated? Goes back beyond GAL RFCs Luca - no updating provide a new mode that can be used that covers everything. Eventually other modes will be unused. Sasha - How does making one more mandatory mode help. Seems like one more mandatory mode too many. Curtis - see list for comments, but GAL should be below PW label toward the bottom of stack. Luca - believe that's the way it is reflected here Sriganesh Kini - if you are doing perf monitoring for MS PW, if GAL label is above wouldn't it be hit at each hop? Luca - GAL shoudl be after PW label, but that's not currently how it is in the draft, must be discussed. Sri - if using without control work and impl is looking beyond label stack, is it still out of band. Luca - if not using CW cannot guarantee it is inband Jia - concerns on the position of the GAL in the label stack. In the draft the GAL is above PW, not addressed in slides. What is situation of whether this will change? Luca - whether GAL is above or below, it will not be examined until packet deliviered to PE that will terminate the PW. If received before PW, sent for further processing. If look at PW label and see S=0 then must be sent for further processing. Jia - may be an issue for MS-PW. Also may be inconsistent if using the GAL for LSP for both PW and LSP. Luca - always using the context. Jia - If GAL below PW label OK, but if above then inconsistent if using with LSP. Luca - then there is a bug. If not bug it would work. Curtis - Using the GAL and TTL at same time is not mutually exclusive in the draft. Could have situations where you want to use both like traceroute. 10 min - Pseudowire Control Word Negotiation Mechanism Analysis and Update - Sami Boutros for Tom Nadeau http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation Sami presented for Lizhong. The solutions allows the CW to be enabled if for example the configuration on CW preferred is changed after initial negotiation. Augments RFC 4447. Draft will be updated and then will be made a WG draft. Luca - This draft deals with LDP, the MPLS WG must review this. The two solutions proposed on the list are the only way that avoid changing LDP rules. Andy - This draft on agenda for MPLS. 10 min - Encapsulation Methods for Transport of Packets over an MPLS PSN - efficient for IP/MPLS - Sriganesh Kini http://tools.ietf.org/html/draft-kini-pwe3-pkt-encap-efficient-ip-mpls Sri presented. This draft is an optimization of the existing drafts when traffic is mostly IP and MPLS. Sasha - Question not to authors, but to WG. What would be wrong with using GRE header and defining GRE PW that could carry everything? Just an additional 4 bytes split from CW to use different OAM. Would not carry additional IP and L2 headers. Why not define GRE PW as the Pkt PW and be simpler to implement. Sri - if trying to do ECMP, would need to look beyond Sasha - Don't need so many mechanism for ECMP creates unnecessary complexity. Don't understand how OAM would work. Sri - OAM shoudl work as for any other PW. Looking beyond PW header is done today. Luca- isn't this another solution to something already working on? Started as simple just put IP packet there, but not that simple. In the draft how would you do a lookup? Because you have some IP and non-IP? Sri - enhancement to the existing Pkt PW. Not all cases supported like Q in Q. Luca - how would ISIS be supported? Sri - single PW would cover ISIS in GRE or noted by CW. Luca - how would you do lookup for mixed traffic Sri - look at CW if IP, then either IP or MPLS, if not process non IP packet Stewart - other draft has been updated. What do hardware folks think of this draft. We concluded if you do Ethernet then it does all that needs to be done. Here optimized the bytes on the wire, but is the cost of processing other packets worth it. Sri - Have discussed with hardware folks, and they are comfortable with encapsulation. Processing non-ip packets is not such a big deal. Matthew - cut the line Broadcom - what probelm are we trying to solve. Saving a couple of bytes is not worth the complexity. Sri - not saving just a "couple of bytes" Broadcom - don't think it is worth it Sri - not a great deal of complexity. Only for non IP packets, and not much complexity there. Himanshu - when you take off layer 2 headers at egress what do you do to put them back. Sri - At destination the layer 2 must be learned by signaling or other ways. George - If you use Ethernet, future proof assumes new protocols will handle Ethernet. Matthew - gauge to make WG draft. More folks in the room don't want to pursue than do. Will take to list whether to make WG draft. 10 min - Pseudowire Virtual Circuit Connectivity Verification (VCCV): An Inband Control Channel using offset - Sriganesh Kini http://tools.ietf.org/id/draft-kini-pwe3-inband-cc-offset Sri presented. Luca - interesting but this is not a PW and doesn't work in the PW architecture. Can't put somthing before the CW at the top of the packet. How to make this work? Sri - only for VCCV message, not for normal data. Luca - How do you parse this? Sri - If you use CW word then no problem Luca - If no control word then need to put this in? Sri - yes Andy - remainder of discussion taken to the list. 15 min - PW Usage Nits - Yaakov Stein LDP Status Messages Sasha - Interesting observation, how does all this interact with Static PW messages? Yaakov - This is for the case where we do use the PW control proocol. For Static PW you don't have control protocol, so you can use BFD. Anything you can do in the static case you can use here. Sasha - we should converge to a single method. We have multiple VCCV types and usage of CW. Luca - The reason that 5085 did not change 4447, is that if LSP dies you will have IP alive. We had to choose one of the protocols so we chose the control plane because it would be less likely to not be available. Already chosen. Yaakov - not trying to change this, but can say that you don't support status TLV so you can use BFD. Luca - want on method for a given PW Rob Rennison - don't want to make use of redundancy bits mutually with BFD. Yaakov - can just negotiate use of status CC Type Usage Carlos - agree you should accept anything (liberal in what you receive) Yaakov - so is there any reason to signal it at all? Luca - looking at all IETF RFCs there's always logical nits. but the common understanding tends to be in one direction. We can't specify every possibility to death. e.g. the router alert stuff doesn't apply to PWEs. Luca - router alert has to be there for IP Yaakov - even the MPLS over IP RFC says you have to support all MPLS procedures (incl therefore router alert) Matthew - need to take remainder of discussion to the list CW Usage RFC goes to great trouble to ensure that CW usage is symmetric. but the L2VPN BGP case allows asymmetry. Is it a general principle that all PWs must be symmetric re CW usage? Actually seen it happen that an implementation changed CW usage during the life of a PWE. Need to take discussion to the list... 5 min - Extension to LDP-VPLS for E-Tree Using Two PW - Daniel Cohn http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw Daniel presented. Luca - Have you considered using an interface parameter as a flag instead of new PW types? Daniel - how would you signal? Luca - It's in RFC 4447. Better than using new PW types. Daniel - OK can take offline. Luca - also you can use BGP AD to figure this out (but that belongs in L2VPN) Matthew - will take remainder of discussion to the list. 5 min - LDP Typed Wildcard PW FEC Elements - Sami Boutros http://tools.ietf.org/html/draft-raza-pwe3-pw-typed-wc-fec Sami presented Luca - so why not use the group ID? Sami - issue is that group ID doesn't cover all bindings. Sami - would like to have adopted as a WG draft. Andy - will take question to the list. 5 min - MAC Address Withdrawal over Static Pseudowire - Sami Boutros http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd Sami presented. Luca - In doing static PW message, tried to get away from reproducing LDP in control channel. Do we really need to do this, or is this a corner case? Sami - needed for redundancy Luca - is it needed for static PW? Sasha - Yes it is important between VSIs. Looks like MAC withdrawal can't coexist with status TLV. Can't send PW Status TLV on same message? Sami - you can. Defining a mode for MAC withdrawal. Sasha - should clarify Gile Heron - should ask list/SPs whether they want to do static VPLS Rob - on static side would be spoke, applicability is not great Andy - will need to take rest to the list 5 min - Stitching Procedures for Static PW in MPLS-TP Environment - Sami Boutros http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-ms-pw Sami presented. Asking to make this a WG draft. Matthew - will take to list 10 min - MPLS LSP PW status refresh reduction for Static Pseudowire - Luca Martini http://tools.ietf.org/html/draft-martini-pwe3-status-aggregation-protocol Luca presented. Luca - trying to aggregate PW status for static PWs. Luca - need to detect PW restarts and misconfigurations Luca - opinions? Yaakov - Way back before PWE3 there was a BoF (CEOP) where this was proposed. Luca - yes but this is MPLS-TP so fate sharing is by definition. 5 min - LDP extensions for Explicit Pseudowire to transport LSP mapping - Mach Chen http://tools.ietf.org/html/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp Mach presented Issue around PWs binding to different PSN tunnels. No way to force co-routing. Adding two optional TLVs that can be carried in LDP. Asking for WG draft. Will take to the list. 5 min - LDP Extensions for Proactive OAM Configuration of Dynamic MPLS-TP PW - Fei Zhang http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config Fei presented Asking to make document a WG document Post comments to the list. ************************************** ********************************************************************** WEBEX INFORMATION FOR THE PWE3 SESSION(S) ********************************************************************** All Webex Info - http://www.ietf.org/meeting/80/remote-participation.html#webex PWE3 Webex Session - https://workgreen.webex.com/workgreen/j.php?ED=151724357&UID=483233937&RT=MiMxNDI=