********************************************************************** PWE3 - Monday November 8, 2010 09:00-11:30 - Valley Ballroom A ********************************************************************** Chairs: Matthew Bocci and Andy Malis Secretary: David Sinicrope 15 min - Agenda bash, WG Agenda and Status - Andy Malis and Matthew Bocci No comments on the agenda. Goals and milestone need updating. Document status: Luca: on pwe3 segmented pw, responded to last email on S-PE TLV. Does not sound perfect but it should do. Question to the WG. Matthew: Issue is that S-PE is well known term. There is a TLV in the segmented PW draft. Luca: Kind of redundant so do not really care which way the terminology discussion goes. Matthew: CEP MIB in IESG evaluation. Tom: Just got to the comments last week so update forthcoming. PW Requirements: needs editorial work FAT PW: Comments received during last call, document sheperds writeup required. OAM message mapping - with Stewart. Stewart: Must congratulate authors on a much improved final version Eth OAM IWK: ready for WG LC. Will go there after this IETF FC last call after this IETF. ICCP and Dynamic MS PW on agenda AII reachability - awaiting Dynamic MS-PW GAL in PW - consensus to adopt as WG draft. WG version not uploaded as of yet. PW redundancy drafts - completed last call, editors need to update. P2MP PWs - on the agenda. ======================================================================= 5 min - Dynamic Placement of Multi Segment Pseudo Wires - Luca Martini http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-13.txt Luca: No slides - draft has been pretty much unchanged for the past year. We did not want to tie this technology to the BGP "add path". We decided it would be easier just to add to the NRI, which would give us the feature of being able to have multiple paths. Given what is in the queue, this should be next to go to LC. Question to the chairs. Andy: It is pretty ready. We have a long queue for LC. No questions. ======================================================================= 5 min - Inter-Chassis Communication Protocol for L2VPN PE Redundancy - Luca Martini http://tools.ietf.org/html/draft-ietf-pwe3-iccp-04.txt Luca: Samer is the most active author. Outstanding issues are distinguishing an existing connect request from a new one when there is a local error. An additional flag will be added to the connect TLV to address this. Second issue is mLACP config mismatch between a pair of PEs. Solution is to NAK rather than ignore. Third issue is also restart related. No way to request an atomic resynch. So we added global resynch capability. Some other edits and a vendor extension TLV. No questions ======================================================================= 10 min - Pseudowire Status for Static Pseudowires - Luca Martini http://tools.ietf.org/html/draft-ietf-pwe3-static-pw-status-01.txt Luca: Clarifications on bypass message. Very strange negative text, so status messages not pertinent to an AC. Weird phrasing. Rephased. Do not want to limit it if new messages pertinent to an AC emerge. Eric Gray suggested some improvements. Matthew: What about AC status bit. You also have AC down? Luca: Can also be applied to mid point PEs. Matthew: need to decide if we are going to do segment based protection. Luca: Could have a situation where by an S-PE wanted to push the traffic away for maintenance reasons. It requires a little more discussion on that point. Stewart: Suggestion that you do not need the ACH TLV, so there is 32 bits you do not need. Luca; Yes I need to update the picture. Luca: We added the S-PE TLV. Segment ID of the last PW segment. What do we want to do next. One is a new editor, Giles. Another draft I did not have sufficiently ready to present on status aggregation protocol should be rationalized with this. Need to see if sufficient consensus to add to a WG document. Issue is if the WG is OK with this concept. No other questions. ======================================================================= 10 min - Pseudowire Control Word Negotiation Mechanism Analysis and Update - Lizhong Jin http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-01 Focused on CW negotiation problem. Nick's draft would also solve the problem. Issue is renoegotation of C bit. One solution is to send a new label request even if a label mapping message received. Next is to make CW non-configurable. Next is to make it configurable. Option 4 is to make CW capability mandatory. Luca: This particular bit of negotiations has caused me pain for 12 years. The protocol is fine, the implementation has a bug for this to be a problem. If the label is withdrawn you SHOULD be starting from scratch. IN any case the protocol works, it is an implementation detail. Lizhong: IN 4447 the node level message processing.. Luca: All the messages are defined, 4447 only defines extensions. Label request is a standard message. Nick: I agree with Luca that it is an implementation issue. RFC is silent on it. ? (Huawei): A see a disruption here. But remapping messages for example. Luca: You cannot change properties of LSPs in flight. To avoid lots of issues with race conditions. ? (Huawei): not sure why label remapping does not work here. Luca: Labels do not carry information about what is in the packet. Once you withdraw a label you put it in the penalty box, for a long time. Stweart: Are you looking for make before break for PWs. Lizhong: Yes. Luca : You can do it today. Use 2 PWs. Nick: One benefit is in a carriers network, SW issue or whatever you did not have CW, but after an upgrade you have it. Would be nice to upgrade without having IT touch everything. Question is what is the best approach. Andy: looking for more list discussion.. ======================================================================= 15 min - Mandatory Features of Virtual Circuit Connectivity Verification Implementations - Nick DelRegno Note: presentation will include short survey discussion http://tools.ietf.org/html/draft-delregno-pwe3-vccv-mandatory-features-02.txt Nick presented: Since Maastricht added some editors, cleaned it up a bit. Some discussion as to how to address, BCP? Next step is accept as WG draft. Luca: Wanted to point out this is already addressed in MS-PWs. 2 is not an option, so we just have 1 and 3. It might be interesting as a WG to sit down, look at all these modes. Rather than a BCP perhaps an update to the RFC. Nick:Agree and that option was discussed. We'll figure this out as we bring this into the WG. Yakov Stein: For no CW, TTL exhaust is the mandatory. And Vice versa. If Rahul: I disagree with the previous speaker, the other way around is the common deployed case. Italo: If you do not have a CW, nothing says it is an OAM packet. Based on MPLS-TP experience using TTL to address an S-PE, somthign extra is required to identify an OAM packet. Need to take into account both delivery (incomplete capture) Matthew: This is exactly why it was mandatory for MS-PWs. Luca: I agree, but his point was different. If you receive a packet in the middle, how do you know it was OAM? Andy: As always decision for WG draft is made on the list. Following the meeting we'll poll the list. Matthew: There is a dependency on CW support. If very few folks support CWs, the conclusion might be different. Renwei Li: There are lots of TTLs, so when we add new labels how can we be sure. Nick: TO be clear this is the PW label. Luca: For the previous document, please be clear if it is as a BCP or update to RFC. Andy: Probably to early to decide that, we can still do the poll without making that decision. Stewart: WG needs some context as to why the draft is being adopted. Andy: Answer is we will discuss this with the Ads and proceed from there. Nick: Moving onto the implementation survey Stewart: Most deployment is in SP networks, but design not confined to SPs. You need to poll the entire community. Cannot make a change to the RFC that strands a community that deployed in good faith. Nick:Survey monkey running till Feb. Himanshu: What is the purpose of this survey. What are you planning to do with this. Nick: First share the results. There is debate on the mandatory CW draft. Any time you update a protocol, you leave the legacy behind. Want to know what kind of impact this will have. Is the problem anecdotal or industry wide. Himanshu: Slippery slope. Kind of a rat hole to go that path. We made a mistake, but we have to deal with it. Nick: Tend to agree but IETF 77 direction was to find out. Yakov Stein: Is intent to quantize deployment. E.g. how many PWs. I know of a lot of small networks running PWs. Several thousand each with a few PWs. How do we capture aggregate, e.g. school districts in the U.S. Nick: Issue is to collate results. Renwei Li: Will we take further actions from the survey. Nick: This is not speaking to anything that is mandatory, it is not exculsive. If there is a resulting new RFC. We do not have an enforcement arm. Ping Pan: I support this, having too many options is [not good]. ======================================================================= 10 min - Mandatory Use of Control Word for PWE3 Encapsulations - Nick DelRegno http://tools.ietf.org/html/draft-delregno-pwe3-mandatory-control-word-00 Nick presented, see slides. Nick: CW already required for most encapsulations. We have VCCV interoperability issues. Ethernet widely deployed without CW. A stickler was ATM n:1 due to overhead. For Ethernet it is widely supported but not widely used. Goal is to accept this as WG draft to make CW mandatory going forward. Complete implementation survey. Update existing encaps. Yakov Stein: Want to remind people, we have a draft on congestion control that used the CW flags. It was dropped because CW not ubiquitous. Getting congestion control VCCV ACh leaves only ATM N:1 where N=1 as the sticking case. Nurit: Happy to see comprehensive table, mandatory cases all looked like legacy services. Need to consider NG services. Renwei Li: By default all encaps should support that. Luca: It is impossible to actually request this particular direction. We cannot change something that is implemented and deployed, especially with an option. During the standards process we can deprecate unused stuff. But this is widely deployed and implemented. There is no way to change this. Many provides to scope jitter do use ATM N=1 mode. Nick: DO not agree, else we cannot go forward. If the WG says here is the new RFCs we can go forward. Luca: If WG wants to do version 2.0 that is fine. Nick: What we want to say is here is a new version and the CW is mandatory going forward. Tom Nadeau: Agree with Nick, point is to address service provider needs not support broken implementations. The point that Nick is making is that SPs have been asking for a while for this function. Stewart: These things are depoyed widely, could create a new PW type and ask for type 2 if SP is interested. Must serve whole community, not just a segment. Nick: we could move forward with a new PW type or a version 2 ======================================================================= 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-01.txt Sri presented, see slides Service is VPWS that can carry any protocol. Reference model is one single L2 circuit. E.g. QinQ. CW signals whether packet is IP/ MPLS or "other". If IP or PLS there is no L2 header. For non-IP/MPLS there is a GRE header. Advantages is less bytes and less fragmentation. Aggarwal(?): Similar to my comment last time. You are saying the payload is not an Ethernet payload but it is an Ethernet service. Where is the Ethernet header? Sri: There is an Ethernet header presented to the user. Broadcom: Where is the layer demarcation, it must have an Ethernet header in the payload. Sri: Lets take this off line. Ping: IP PW defined with ARP mediation long ago. Mac headers removed and added at the network edges in that case. Sri: There is 4 different subsets of the service carried in the draft. Aggarwal?: but the draft clearly states it is an EVC service Take the discussion to the list. Luca: How do you plan to fragment. PWs cannot be fragemented. Sri: You can use a smaller MTU or the PW fragmentation mechanism based on the CW. Luca; We cannot fragement so do not understand what you are saying. Sri: You may have to fragement at the end device for a smaller MTU. Luca: End device fragmentation is a problem. Matthew: take to the list ======================================================================= 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-00.txt Sri presented, see slides Proposal is to extend CC type 3 as it is required for MS-PWs. Start VCCV CC at a fixed offset from the PW label. Intermediate bytes set as pseudo flow header. 64 byte offset. Himanshu: where does the actually data come from. Sri: Pseudo flow header relates to what ever flow you are trying to troubleshoot. Only useful bytes are those used by intermediate nodes. Himanshu: Sounds great, but you are making guesses as to how P routers select ECMP paths. We are already overloading the edge. Sri: You do not want too much knowledge of what P routers do. Himanshu: You want to fate share with the user flows. Lucy: How does this support IPv6 or IP tunnel. Sri: Bytes should be whatever header you are impersonating. The 64 bytes is unstructured. Lizhong Jin: I agree with the problem statement. ======================================================================= 10 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-01.txt Mach presented, see slides Problem statement is mapping PWs to lower layer LSPs. Lizhong: I don't think it is a good idea to bind the layers together. Mach: This is a requirement for MPLS-TP networks. Solution does not consider these architecture scenarios. Lizhong: Already some protection for tunnel, when underlying tunnel switched. Do you signal PW again? Renwei: We can have similar situations in multicast, where we want to map to particular tunnels. You can unify the binding mechanisms with multicasting. Ping Pan: I was hoping for more detail. Great idea, we need to work it further. (?) Do not think it is a good idea to tie layers together. Ping: Today we do combine it but do not signal it. ======================================================================= x5 min - Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP - http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-01.txt Matthew: Note draft name change, this is a WG draft. Luca: draft-ietf-pwe3-p2mp-pseudo-wire needs a new editor. Document is 90% there, but editor as maxed out. Nice if someone can pick it up. ======================================================================= x15 min - Using the Generic Associated Channel Label for Pseudowire in MPLS-TP - Luca Martini http://tools.ietf.org/html/draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Luca: Simple draft, SHOULD be able to use the GAL for PWs in MPLS-TP. Plan to go to last call as soon as possible. Should go quickly. Generated a VCCV discussion. Now that we can use GAL for PW, do we need multiple VCCV types? Yakov Stein: Bad idea. Himanshu: Request on the previous draft that I want to see in the minutes. There is an IPLS draft in L2VPN that uses MP2P PW as well. Would like this as an option. Luca: this has a return label for the PW, so should do what you want Himanshu: want third options multi point to point PW. Luca: the source is the root Himanshu: Leaves must also generate to the source. Luca: this document is bidirectional so leaves can send data to source Himanshu: will discuss offline Yakov Stein: Meanwhile, back at the GAL. The abstract says somthing like this "This discusses PWs over MPLS-TP and therefore proves we should use GAL everywhere". The jump in logic escapes me completely. This pushes us up to 5 or 6 options GAL for PW is restricted by current RFC. Tom N: One goal of MPLS-TP is that as much of MPLS-TP extension be folded back into MPLS so we have one consistent way of VCCV. This is much like the previous discussion. DO we want to fix stuff or simply add options. GAL is a good idea, but one of the TP core requirements is that stuff get folded back and we have to retrofit implementations. Luca: Today PW defined in MPLS-TP are fully compatible with MPLS Andy: move this to the list. ======================================================================= 10 - min - LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network - Yuanlin Bao http://tools.ietf.org/html/draft-bao-pwe3-pw-transfer-00.txt Yuanlin presented. See slides. Merges several drafts and contrasts approaches with make before break. Communicate decoupling the PW from the TLDP session. Once everything taken down you can kill the session. Andy: We'll take comments on 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-03 Fei Zhang presented. See slides. Updated for SS to MS PWs. Renwei: What about race conditions in setup from either end. Follows the label mapping messages so most recent overrides the first one? Fei: Withdraw is sent by PE with the lower ID to avoid this. Renwei: As a receiver how do I know what is the most recent message. There is a disconnect here with the timing. I do not see an answer in the presentation. Andy: Take it 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-00 Sami presented. See slides. Sami: Draft renamed to focus on MPLS-TP, originally presented in Maastricht, but added MPLS-TP to the name Believe the draft is needed, want to request WG adoption. Matthew: Who has read it? Not very many. Read the draft and discuss on the list. ======================================================================= - Closing - Matthew Bocci and Andy Malis Matthew: no 2nd session, printed agenda not right. ********************************************************************** WEBEX INFORMATION FOR THE PWE3 SESSION(S) ********************************************************************** Audio Stream: http://videolab.uoregon.edu/events/ietf/ietf796.m3u Webex: https://workgreen.webex.com/workgreen/j.php?ED=148485017&UID=1191116402&RT=MiM0 Meeting Number: 961 904 080