Monday, March 10th, 2008 - 15:20 - 17:20 ---------------------------------------- CHAIRS: Danny McPherson & Stewart Bryant SCRIBE: Matthew Bocci ------------------------------ WG Status and Update - Chairs ------------------------------ Agenda agreed. 20 RFCs to date 3 held up MIBs pushed through to IESG. MS-PW requirements - many security requirements on this. Trying to resolve these. There is a backlog behind these. ATM MIB a little late - updated now Work in progress - many held up due to MS-PW reqs. Redundancy - now a WG item. No negatives on the list. A few comments on list about couple mechanisms together. Need some work on other MIBs. New charter being worked on OSPF routing draft - needs to coordinate with the OSPF. Chairs will check with ADs that this is OK to take on. ---------------------------------------------------------------------- PW Redundancy Update - Praveen Muley (Praveen.muley@alcatel-lucent.com) http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-redundancy-bit/ draft-ietf-pwe3-redundancy-00.txt (posted to list) ---------------------------------------------------------------------- Gives an update on the drafts. Both adopted as WG docs. Major addition is revertive behaviour. Framework and Requirements: - added new co-authors - added new definitions and terminology - aligned text to be more to FR like - added generic PW requirements Shows new terminology. Generic PW redundancy requirements - 1:1 is mandatory, N:1 optional 1+1 is left for further study. Non-revertive mandatory, revertive optional. Added operational requirements. Preferential forwarding status bit draft: - updated scope of protection capabilities achieved - - revertive/non-revertive behaviour - Added appendix Next steps - manual lockout case - more feedback from WG requested Danny: has evolved and progressed and fine to go forward Yang Yang: ITU-T have defined some linear protection. Better to align with ITU- T. Dave McDyson - I agree. Important clients are TDM etc that have their own native protection schemes. Framework would be a good place to map native service terminology and make appropriate references. ------------------------------------------------------------------- MPLS & Ethernet OAM Interworking - Dinesh Mohan (mohand@nortel.com) http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt ------------------------------------------------------------------- Presented by Nabil Bitar. Current PWE3 OAM message mapping does not address interworking with Ethernet OAM. Since then, good progress in Ethernet OAM space. This draft tries to complement the mapping draft with interworking with PWs. Shows reference model. Consistent fwd/reverse defects with message mapping draft Explains PW and AC defect detection options, and the mapping of reverse and forward defects between the Ethernet AC and the PW Next steps: Could merge with oam-msg-map or pursue as a separate draft. Yaakov Stein - this is important work. Have you also looked into .3ah? We need this covered too. Nabil: I thought we did, because we cover link level defects. We need to go back and make sure this is covered. Ali Sajassi: This is a very good comment. Counts for ELMI too in MEF. Luca Martini: I have asked for this years ago, and chairs did not want to put into. I am in favour of putting this into message mapping. Stewart - don't remember, but msg-map is quite mature Luca Martini - this will generate more interest again and we can progress this. Stewart - Monique is the editor and she just refreshed it. It would be good to review msg-map, and progress Ethernet separately as some more material to add. Yaakov Stein - agrees should be separate, and not hold up message map. Danny: is there consistent terminology with OAM and redundancy drafts? Nabil: The mapping draft is most advanced, and common authors with redundancy, so hope they are consistent, but need to check. Stewart: if existing OAM message mapping draft is nearly done, then keep separate so as not to hold up. Luca Martini: what will the IESG say without the lack of Ethernet? Stewart: put in informative reference to Ethernet doc. Co-authers need to add informative reference, and then we will last call it. George Swallow: The way the industry is going, the Ethernet is the most important part. ----------------------------------------------------------------------------- LDP AII Reachability - Frederick Jounay (frederic.jounay@orange-ftgroup.com) http://tools.ietf.org/id/draft-delord-jounay-pwe3-ldp-aii-reachability-00.txt ----------------------------------------------------------------------------- First version of the draft. Explains rationale. Procedure to populate AII routing tables in first hop S-PE via LDP Intended to complement IGP/BGP mechanisms Problem statement: Typical to access networks. No IGP or BGP - p2p physical connectivity But run LDP for PW setup IP and PW addressing separate Does NOT replace routing protocols Advertise only locally attached AII Explains proposed mechanism Next steps: - feedback from WG - add some extra scenarios (dual homing) - extend to AGI as well? Luca Martini: What do you mean by extend to AII? Fred: Just mean also use for VPN provisioning using LDP Luca Martini: Just haven't found a good application for the AGI in this context, but would like to know if you have one. Fred: Network autodiscovery populates on S-PE/T-PE, but VPN autodiscovery must only be at the end point Hamid Ould-Brahim: on your 1st slide, what do you mean by interwork with other auto-discovery mechanisms? Fred: the S-PE can relay this info based on BGP or IGP Luca Martini: confusing term is auto-discovery. It should be over routing protocols. Stewart: Who is interested? Lots Stewart: Who thinks this is a good starting point? Quite a few --------------------------------------------------------------------------- Conversation Hashing for Pseudowires - Vach Kompella (vach.kompella@alcatel- lucent.com) http://tools.ietf.org/id/draft-vkompella-pwe3-hash-label-00.txt --------------------------------------------------------------------------- Discussed a long time ago, but no demand at that time. Then Stewart brought fat PW draft, so I wanted to add this to the pile. A PW can carry many flows, and do not want PW to follow one path if the PW has many flows that can follow different path e.g if PSN has ECMP or LAG etc Explains PW hashing fields t Could use hack such as looking at 1st nibble, but complex and only works if it is a 4/6 for IP. Can we do something intelligent with the label stack? Shows an example. Solution proposes that 2 ends of PW exchange a range of has labels that can be used by ingress side to hash traffic and pick a next hop for trhe PSN. Packet: tunnel, hash, PW label, payload At LSR, LSP swaps on tunnel label. At egress, tunnel popped, hash is popped, and then you proceed based on PW label. Benefits include the fact that ingress holds one set of labels per peer. Egress distributes one set of labels. Extensible to PSNs and to BGP VPNs. Hasahable info is stable per flow, uses MPLS methods, requires no changes to the CE, minimises the labels allocated and programmed per node. Acknowledges that some P routers don't hash this way (order of labels), would like to understand if we should… Shows some considerations on extending to PSNs. Ingress PSN- hash label at the top of the stack. Questions - where should we put hash label? I think it should be before the PW label to leave PW context processing to the end. How does this work with existing implementations? Is this a new FEC? Or just a capabilities exchange? Diversity for BGP label exchanges. Should this be done in MPLS WG? Could this be used to explore PW paths like LSP-ping multi-path? Danny: please address these questions first, then we will go to regular questions Yaakov Stein: yes, place to put it is between PW label and tunnel. How does this work for LSPs. st Vach: For PW, 1st guy gets a packet with n different hash labels, to choose n different next hops. Discussion taken off line Rahul : not sure if this applies to IP VPNs because IP header involved. PSNs could be an issue due to application level entropy… Kireeti Kompella: good stuff here. There are a lot of things you have not done quite perfectly yet. Happy to help. In picture, how do you get a good hash if you have 20 bits of option and only using 3 bits? I think you put labels in wring place - talk about off line - but do agree we need to extend to IP VPNs and PSNs. Stewart - include me in this. Kireeti Kompella - I agree bottom is the right place. Would like to take out of PWE3 for now, and talk among all the interested people. Then we can figure out how to proceed. Danny: agree Don O'Connor: is this only for best effort? Vach: this is not developed well enough for multiple levels of service Don O'Connor: should this be in the charter? Vach: Could use diffserv TE and use different hash label Stewart: Not clear that you need to know this Don O'Connor- if you want to groom traffic by traffic class in an S-PE this should be allowed Ali Sajassi: have you considered impact on native and PW OAM? Vach: No, not yet Ali Sajassi: It has impacts and needs to be considered. If you exclude OAM for the time being, why not assign multiple PW labels? Vach: Service Providers have large numbers of PWs. That would not scale. Amount of churn on every failure would be too high. Ali Sajassi: need to address OAM George Swallow: only time I looked into what labels are hashed on, everyone hashed on bottom label. Could do this survey again. If this a general mechanism, should not be in MPLS. I would like to be on this mailing list. Stewart: issue that if we do this in MPLS, not clear that the signalling for PS will work properly. Kireeti Kompella: need to do something for underlying tunnels, and make some generalisation about load balancing. We can then farm out the signalling to individual groups. Framework in MPLS. Stewart: Agrees to that. Vach: requirements come from providers, and they have lots of differences, but there is also differences on the implementation side so would like to not just give to a set of providers. Stewart: My draft was with DT because it is a real SP problem. Mark Townsley: No problem in defining this in MPLS, but pressing problem is here. Does not seem all that pressing for the IP case. Dave Allan: Would echo Mark's comments - for something that can hash IP now, too much complexity. Also need to ensure OAM flows fate share with combination of PW and hash label. Luca Martini: Comment on both drafts. Does not solve a generic problem. Only works if you can identify a flow to has on the input. What causes such a large flow? And IPSec flow from a bank? This only works if you can identify the flows on ingress. Shane Amante: agree this belongs in MPLS. Mark and Rahul had some discussions about IPVPN. This is needed for that because customers USE THESE FORLARGE FLOWS. Danny - Need framework and requirements and coordination with fat PW stuff. --------------------------------------------------- T-MPLS Update - Stewart bryant (stbryant@cisco.com) --------------------------------------------------- Describes SG13 plenary in Seoul. T-MPLS protocol and requirements. Q5/13 in Seoul. Meeting attended by 3 IETF Ads, plus 1 from IAB. Goal to represent comments from IAB DT. Considerable work on requirements - amended to become implementation neutral requirements, which were published as an informational supplement. Available through ITU-T web site. Non-normative, but lots of useful info on improving OAM for MPLS and PWE3. G.8114: no technical work. Question recommended that Recommendation withdrawn from AAP and publication stopped. SG5 plenary: Considerable work done before meeting on structure of JWT. This was approved. Because of the pending decision on JWT, all related tech work on T-MPLS halted until decision taken. JWT task to recommend option 1 or option 2 to ITU management. Small team of experts picked. Jointly chaired by David Ward and Malcolm Betts. Based on technical studies of 2 large study groups - IETF interop design team, and ITU-T ad0hoc group. IETF Interop design team will perform technical analysis to determine what ITU or IETF docs/technology mods/extensions needed. Advise JWT on the deliberations. IETF MPLS interop DT chaired by Loa. Must report by April deadline. Technical work is only to understand what needs to be done. Design will be done in normal standards process. Shows work areas. ITU Ad Hoc group investigates technical info needed to decide between option 1 and option 2 JWT will compile results of 2 support groups and make a decision. Regardless of option 1/2 decision, we have learned a lot about OAM requirements. Will be a draft on this. There is also mis-understanding about the use of the EXP bits. There will be a draft to clarify this as well. Don O'Connor: what about protection, data plane, etc Stewart: the only thing we can really do is reverse engineer the other documents, as there are no requirements for these. Don O'Connor: what is ITU design team going to be doing? Malcolm Betts: we had a n=meeting in Geneva for 2 days. We developed some requirements, and posted on ad-hoc teams FTP site. We should have some improved clarification on requirements in the next few days. Don O'Connor: so if option 1 is chosen, future methodology is 1 DT with requirements? Stewart: some things will be done here, but some things will happen over in ITU e.g. G.805 modelling. But MPLS technology extensions have to happen here. Malcolm Betts: agrees. Note these design teams have no authority to change IETF or ITU-T documents. These have to be done via regular standards process in the appropriate bodies. We also need to improve liaison process. Stewart: There is a common agreement that we will work together Danny: Appreciates the incredible amount of work done. Thanks to everyone. ------------------------------------------------- PW Multiplexing - Yaakov Stein (yaakov_s@rad.com) ------------------------------------------------- No draft on this. Heard a bit about protection and load balancing today. These were held over from last time. This is some architecture work. In PWE3 arch, we have an element that can help us. This is a PW Mux which is based on the forwarder in the arch draft. A forwarder gives you a many-many connection. Can be used for protection, AC protection, and PW load balancing and inverse mux. Doesn't think label space exhaustion is a problem because 2^20 labels Explains 1+1 protection. PW mux maps AC to appropriate PWs. 1:1 can use PW redundancy signalling, but then PW mux makes the decision on forwarding. 1+1 AC protection: AC mux, and associate multiple ACs with single PW label 1:1 AC protection : again map single PW label to multiple ACs. Load balancing and inverse mux: use all PWs at same time, but not for all the packets. Proposal is for pure architecture work. Need a single method for PW protection, AC protection and load balancing and PW mux. Means a single label for associating PW labels to AC IDs. Designating PW status Signaling between forwarders Sasha V: agree with Yaakov, and 3985 says must be per-tunnel, but 4447 says must be per-platform because of MPLS arch requirements. Can you map CE dual homing to this? This is not covered. Yaakov: why is this not 1+1 AC protection? Sasha: Because not one PW Yaakov: This is a very important use case. If it cannot be included, we should see if we really want to proceed. Andy Malis: on ACs, why not just use LAG or multi-link Yaakov: could do, but this is a single AC from arch point of view. Sure you could do that. But that is not using the function of the forwarder. Andy Malis: so why is this needed? Yaakov: might not be Ethernet, might be ATM IMA etc. Dave McDyson: why can't these just be native service protection? Yaakov: If you have native service protection, go ahead and use it if you want. Dave McDyson: is this really a requirement then Ali Sajassi: so you are proposing multiple PWs per AC for load balancing? Yaakov: yes Ali Sajassi: we have an internal PW ID and a hash ID, whether you map into a single or two labels, that is only an encoding issue. Yaakov: might be computationally more expensive with two labels that you have to pop. Ali: 2 issues: number of labels and processing in the PE. Processing in the PE is not an issue. Stewart: putting an extra label in is not computationally complex. Danny: proposal is that you publish a draft on anything else you want to discuss. Yaakov: wanted to have presentation because wanted to gauge interest Stewart: touches on a number of areas Danny: could submit as a draft this is the appropriate way to convey this. ------------------------ Meeting Closes (early!).