IETF-72 pwe3 minutes Tuesday, July 29th, 2008 а 15:20 а 17:20 ---------------------------------------- CHAIRS: Stewart Bryant & Matthew Bocci Secretary: David Sinicrope 20 mins WG Status and Charter Update а Chairs Stewart presented WG status. See Stewart's slides on PWE3 Status above. The MPLS transport draft will be taken over by MPLS-TP, and can be completed or abandoned. What does WG want? The work has been taken over by events that will serve the purpose of the draftpurpose. MPLS-TP will be handled in a dedicated meeting tomorrow (Wed 7/30) as a joint meeting between L2VPN, PWE3, MPLS and CCAMP. Work on MPLS-TP will be coordinated between the 4 working groups. All drafts contain the string 'mpls-tp'. There may be some LDP extension work for PWs but not LDP work as such. Charter See Charter slides above. The working group was rechartered a few weeks ago. Main responsibility was clarified which was necessary for MPLS-TP. The change process in RFC 4929 applies to PWE3. The boundary between L2VPN and PWE3 for P2MP and must be coordinated. Transport applications Congestion PW Types Security Multipath Lucy: Is multipath in context of ECMP or link bundling? Stewart: It is written as ECMP, but link bundling may take advantage of the same mechanism. Applies to both. Lucy: In ITU-T, they are working on composite link similar to Multilink. Would like to know who is working on requirements so we can send work to ITU-T. Stewart: There are several drafts e.g., Stewart and others. Please send note to list saying who in ITU-T is working on it and we will consider liaising to them. The work identifies methods by which PWs may take advantage of transport between two PEs Deliverables TCM а The list of deliverables was done at the last minute and may not have been quite right. TCM will be removed until requirements are settled. Sasha: а Will call on network layer to get packets to right place. For P2MP we would use lower layer fabric which we wonеt create. Was there a change to the charter text? Does the change take into account the requirements of P2MP on the PSN? Stewart: No intention to do anything severe to the charter, but may have put words in to allow us to deal with multicast. Charter is to support P2MP. Intent is that we are a layer that sits on a PSN. This should be clarified if needed. Sasha will look and see if clarification is needed and let chairs know. Himanshu:- last bullet of PW type slide а What is meant by вunless the network layer protocols are IP or MPLSг. We have an existing IP PW, requirement for MPLS PW, carry MPLS from one provider over another provider and provide isolation. If the access is MPLS is what is meant? Please clarify point. Discussion and update on message mapping instead of 5 mins- OAM Message Mapping а Luca Martini (lmartini@cisco.com) http://tools.ietf.org/html/draft-ietf-pwe3-oam-msg-map-06 Matthew Presented chairs view of OAM message mapping draft situation - See slides: message map draft updated from v6 to v7. Done without all author's knowledge. Also there was a discussion in Philly on MPLS Ethernet OAM and the WG was against merging the draft. However, the text was incorporated into Message Mapping draft v7. This was done in good faith and the draft needed significant revision. Way forward: There was a call for consensus on list: The Ethernet draft should be kept separate as a WG draft from the Message Mapping draft. But Message Mapping draft is not ready for last call. Need small group of editors to perform tasks listed. Will be asking to have it happen expeditiously! Need draft, edits and LC to be ready for IESG by next IETF meeting. Yaakov S. а What happens to the Ethernet portion? Does this imply that the Ethernet document will be its own WG draft? A: Yes. 2 drafts and both handled as quickly as possible. Luca а OAM Message Mapping draft had some mention of Ethernet but not complete. Need to remove Ethernet from Message Mapping draft and proceed with separate doc. Yaakov S. а With the text taken out, please put remarks in the Message Mapping draft explaining why Ethernet was removed for IESG. Luca а No, just need informational reference in scope pointing to Ethernet document. Sasha а OK with way forward, only reasonable way forward given history. Wanted to bring groupеs attention that there is problem with draft, doesnеt specify a single mandatory option on Ethernet OAM specifications. May be enough to adopt as WG doc, but should be addressed. Ali а prioritize options? Yes. Will be taken into account 5 mins а MPLS Generic Associated Channel а Matthew Bocci (matthew.bocci@alcatel-lucent.co.uk) http://tools.ietf.org/html/draft-bocci-pwe3-ge-ach-00.txt Matthew presented slides. Objectives: This will be presented during MPLS-TP session tomorrow. Lots of work over years on OAM to provide functions listed. Objectives of the draft: uses PW associated channel and runs many different things over channel. What new ACH channel types are required? а VCCV specs carrying LSP ping and BFD, but need others. Next steps: confirm full list of channel types, list feedback and move to WG. Yaakov S. - fully support part about more channel types. Using for LSPs and PWs. The mechanism uses the control word, so how do you use for LSPs? Would need to put in a control word on LSP but restrictions on how it can be used. Stewart - LSPs use a reserved label with an ACH following which tells more info about the packet. So you can run OAM over LSP in same way as over PW. Sasha - Same question only more specific. What about an LSP carrying IP? Stewart - Reserved label is method of record to say that what follows is ACH. If what is carried is IP, then ACH would tell. Sasha - This must be addressed so that it doesnеt break existing MPLS networks. Stewart - It is being addressed in MPLS WG, and in MPLS-TP Sasha - Should it be moved to MPLS wG, no. Yaakov S. - What is the difference when using this between IP PW and an LSP carrying IP? Stewart - There will be a set of drafts defining the code points and using same codepoints as VCCV. Lucy - Is it possible to access this attached channel in the middle of the PW? Stewart - No, but eg. If PSN TTL expired then packet is accessible and could tell it was OAM. The point here is just to extend the ACH. If you have LSP between two PEs can channel be accessed from a PE? Regarding the вWhat new ACH Щг slide: Is this related to MPLS-TP, or any SCC? Right now intended for MPLS-TP, but could be applied to others. Sasha а scanned draft and it doesnеt cite reserved label. Stewart - This draft allocates protocols, there are separate drafts for reserve label and others that will be addressed tomorrow during MPLS-TP session Sasha - Too complex doc structure Loa - This is a complex doc structure. Any ideas for simplifying are welcome. Continue discussion on the PWE3 list. 5 mins а MPLS & Ethernet OAM Interworking а Dinesh Mohan (mohand@nortel.com) http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-01.txt (skipped) 10 mins а Inter-Chasis Control Protocol а Luca Martini (lmartini@cisco.com) draft-martini-pwe3-iccp-00.txt Luca presented slides above: There are several requirements in the draft and in the slides. 4 messages : Connect, Disconnect, Notification, Application Data Proposed solution: There are several existing protocols but closest is LDP. Transport Details: all requirements listed are met by LDP, resiliency can be accommodated by making extensions to LDP Node failure: existing mechanisms can be used - /32 next hop tracking (if fast enough), BFD, tie to TE tunnel draft covers procedures, setup, etc. ICC Deployment: Setup Procedure: Luca walked through the setup bullets listed. Added a protocol version to ICCP just for ICCP in case we do something different then it makes it independent from LDP. Feedback? Several proprietary versions floating around, but providers want standardized version. Sasha: RE setup procedure: For RG membership, does it imply that technology is limited to no more than 2 participants? Luca: No. Rahul: What is applicability if you are using BGP autodiscovery? Luca: Like ships in the night. BGP used to configure, not for redundancy. Rahul: Not correct because here discovering redundancy groups. BGP also discovers these groups Luca: BGP discovers a path, not what is being done here. Rahul: BGP discovers other sites that can be multihomed. Will take discussion offline. Rahul: The PW group has already addressed PW redundancy what is done here is over and above that? Update draft and make clear what applicability to this wG is. Luca: It addresses new issues. Shahram: What is the applicability to PWE3? It is modifying LDP, but this must be done in MPLS WG. Wanted to get this group to look first then get MPLS to look at it. Not moving to wG draft at this meeting. Next step, but not yet. Ilya:When you establish a PW within a redundancy group must it be in the same AS? Or can it work across ASs. Luca: Meant to work in the same domain. Ali: Add to comments Luca made: application is for access network. You donеt need to run MSTP. Alex: applicability to PWE3 is valid in PW redundancy case PWs terminated and must coordinate switchover. Continue discussion on the PWE3 list. there are many protocols that do this, but need one for here, and LDP has most of the needed features 5 mins а 802.1ah Pseudowire а Luca Martini (lmartini@cisco.com) http://tools.ietf.org/html/draft-martini-pwe3-802.1ah-pw-02.txt Ali: see slides done over 1 year ago for clarification on why we need this. Need this special Eth PW when want to diff ITAG from VID. This is important when PEs are connected to BCB (not BEB) Based on 4664 and bridge-interop draft. Need ISID translation over MPLS core, which is easy to do via this new PW type (for a given ISID, may need multiple translations) Don't need if BEBs do ISID translation to common value, then raw Eth PW is enough. Requests to become WG draft. Nurit: where would the translation be done? Ali: In the PEs on both sides. Think of the access as regular .1ah access. Sasha: RE вWhy it is needed?г Slide: Last bullet: Not speaking about VPLS just PW, PW given between 2 PEs and defined by attachment circuit Ali: defined by forwarder which can be Pt Pt. Sasha: is it applicable to pt pt or vpls?? Why do we need it for a Pt-Pt PW? Ali: for any given two pts you do 1:1 translation, but looking at overall service. On a Pt-Pt if you donеt want to translate in the NSP, transport whole .1ah. When want to translate ISID without incorporating bridge module. Dave Allan: general question, what problem are you solving? IEEE would have a common ISID in VPLS domain. Don't need otherwise unless > 16M services. Is the objective to go beyond 16 million services? Ali: No. Taken to list. 10 mins а Generic Ethernet PW а Vach Kompella (vach.kompella@alcatel-lucent.com) http://tools.ietf.org/html/draft-vkompella-pwe3-ethernet-pw-bis-01.txt See slides. Vach presented. Trying to slightly redefine raw mode PW not come up with new PW type. Draft explains carefully what NSP and PW function should have been. NSP function SHOULD be "Ethernet aware" (VLAN processing etc) but "PW unaware", while the PW functionality should be PW aware but Eth encap agnostic Example - NSP expects port to have Q-tag but PW functionality would always put the same label. The PW portion (at both ingress and egress) shouldn't care about VLAN tags. Next Steps: Differing opinions about what to do with NSP capabilities. The NSP capabilities TLV says what NSP is doing on each side of the PW. Before that, we need to agree that the PW should not care whether or not Ethernet has a VLAN or not and is just transporting an Ethernet frame. How do we specify something useful at both ends of the PW to get consistency on how the PW should work? Is there a good way to express this? If not is there some method to define this? Ali: without NSP capability why canеt you use existing raw mode. Vach: Donеt want to have a raw mode, tagged mode and an .1ah type. One type. Ali: We donеt need NSP capabilities because it must handle to many permutations. Taken to mailing list. Luca: Want to use raw PW mode and want to specify what the NSPs will do and like inverse draft and remove other modes. Can you rewrite draft to be clear that .1ah and VLAN are to be subsumed? Still not sure how easy to express NSP type, but wanted to attempt something. Need to work out details, but not for this discussion. Don O'Connor: Should tag process not be defined. Vach: not defined as PW, but defined as part of NSP. Don: Then the architecture changes? Stewart and Vach: No,it's in the NSP and PW Architecture doesnеt define NSP functions. Rahul: Agree with limiting to raw mode, but need to define what problem we are trying to solve Shahram: Agree. Original idea of reducing lookups is no longer relevant. Shane: What are we forcing on operators to do when they are not able to enable a PW? Would like capability to set up PW and expose information on both sides to do debug, but could also look at it as e.g. donеt bring up if MTUs donеt match. Need to be flexible. Stewart: Please make that point on the list. Continue discussion on the PWE3 list. 5 mins а Load Balancing Fat PWs а Stewart Bryant (stbryant@cisco.com) http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw See slides: Stewart presented. Multiple PW approach removed only LB label method left. Added text that can not use labels 0 .. 15. Stole text from Vach's draft on initialization. Several changes since last IETF. The difference between this draft and vkompella is whether to signal the label or not and that this has label at bottom of stack. Willing to add signaling as option if see technical reason. TTL value is now set to 1, but with PHP may cause problem. Note that also good for link bundling. Should the name be "load balancing" or "entropy label" ? Propose accepting as WG draft and adding authors of vkompella draft. Rahul: Signaling labels: donеt see a need for signaling labels. Removal is a good thing. Luca: would like to make it clear that it solves only a small set of problems. This assumes that you can tag all internet flows which is rarely the case. Must make applicability clear. George: Need to clarify applicability, may not always work. Shane: Disagree, difficult, but not impossible to identify flows. If done at edge of network can be done, rather than at core. Lucy: Agree w/ Luca. Could change to flow aware PW. Stewart: Need to have a more politically correct name. Giles: What is point of a PW carrying internet when other mechanisms exist? Trying to do traffic engineering which means that traffic for a flow should be bounded. Now can you bound individual flows? We don't need since we have an IP PW, and there is already IP ECMP. Also, don't believe that can balance this way. Continue discussion on the PWE3 list. 10 mins а PW Bonding а Yaakov Stein (Yaakov@rad.com) http://tools.ietf.org/html/draft-stein-pwe3-pwbonding-00.txt See slides: Yaakov presented Giles: This doesn't solve problem as before. Donеt you need shared memory between line cards? YS: No, only need to re-sequence at egress. Giles: You didnеt really answer question. How do you do multiple 10G links? YS: Was meant to address multiple DSL or PON links, not 10G Luca: Agree w/ Giles. Works fine for speeds usually concerned with, but not doable at high speeds. Note the speeds intended in the draft. YS: Agree Sasha: doable, just take in mind that the operator will need to bound the degree to which the diff delay can be compensated. Rahul: Is this theoretical? YS: No, providers asked for it. 5 mins а LDP AII Reachability а Frederic Jounay (Frederic.jounay@orange-ftgroup.com) http://tools.ietf.org/html/draft-delord-jounay-pwe3-ldp-aii- reachability-01.txt See slides. Fred presented updates on LDP-AII-Reachability draft. Uses FEC 129 AII routing tables over LDP when no IGP/BGP. New AII LDP address family. Various word smithing and readability fixes. Asks to make WG doc. No questions. Question on WG draft will be sent to list and Stewart will determine WG consensus. There was support in the room to make the document a WG document. 5 mins а P2MP PW Requirements - Frederic Jounay (Frederic.jounay@orang-ftgroup.com) http://tools.ietf.org/html/draft-jounay-pwe3-p2mp-pw-requirements-02.txt See slides above. Fred presented. Stewart tried to cut him off due to limited time. Asks to make WG draft. No questions in room due to time constraints. Will discuss on the list whether to make a WG draft. 5 mins а PW Congestion Framework а Stewart Bryant (stbryant@cisco.com) http://tools.ietf.org/html/draft-ietf-pwe3-congestion-frmwk Stewart quickly reviewed congestion draft. 1. Did congestion work with input from transport ADs. 2. No input from transport area telling whether we are on right path. Work is on hold until feedback from Transport Area. 3. Was discussion on list whether methods are fair. Focus is safety not fairness 4. Stewart used the term flows as unit of currency if another unit is more applicable, then we can consider it. Luca: if they arenеt blocking the document then they give up their right to provide feedback. They should not be blocking document. Need to know if we are on right direction. Who in transport should we be asking? Ads? Bob B. I have commented. Stewart - need a complete review. 10 mins а PW Congestion - Yaakov Stein yaakov@rad.com) No draft - Not presented due to time constraints. - Continue discussion on the PWE3 list.