MPLS Working Group IETF 70 December 2007 WG status (Loa) 4 new RFCs. Many thanks to Ina/Bob for LDP docs. Nothing in RFC-ed queue or IESG review - sign that the process has improved massively and that we're no longer getting impossible refs in docs. Question on LSR self test. George - issue is that there are no implementations. Had the document returned to the WG. Will keep alive until there's an industry demand for it. Various (21) WG drafts progressing. LDP capabilitiess will go to IESG shortly. 2 docs pending WG last call - upstream label/multicast encaps. Will issue last calls after IETF. T-MPLS design team (Stewart) Concerns have been raised about T-MPLS. IAB/IESG liason was sent after the last IETF. Concerns that T-MPLS is detrimental to the Internet. Two options were offerred: 1) work together in IETF - extend IETF MPLS. 2) split T-MPLS off entirely ITU-T discussed the liaison. Option 2 was rejected and it was agreed that IETF is where MPLS gets done, but that SG15 are the experts on transport. A joint design team being discussed by ITU/IETF. So anything needed and not in RFCs will be brought through team, and ITU work modified if needed to make it IETF-compliant. Plan going forward is to use the IETF process for any extensions/modifications of MPLS. Will use normative referencess to IETF docs, rather than restating in new language. Proposal is that IETF docs are normative when quoted, but equally ITU docs will be normative when reffed by IETF. A key issue revolves around label 14. The issue is that T-MPLS OAM redefines behaviour of label 14 and of EXP and TTL bits. Needs IETF standards work to modify RFC3429 so propose to hold off on ITU specs until that's done. Joint team needs management of ITU/IETF to agree. So doing interim work already. Small IAB team identifying IETF actions and any incompatibilities etc. So team has its work cut out. Work will eventually move into joint team. MPLS/GMPLS Security Framework (Luyuan) Status update - history from IETF67, became WG after IETF69. Minor changes only since then. Want more feedback - not had enough yet. Initially there were concerns on MPLS/GMPLS security. Issue is that individual docs weren't addressing it. The scope is anything to do with MPLS/GMPLS security. Inter-provider a big concern. VPNs are already addressed in RFC4111 so less discussion here. Don't want to go into general security practice - MPLS-related material only. Recap of contents: Defines trust model up-front. Differences between trusted/authorised (other provider in inter-AS is authorised, but not trusted). New threat models around MPLS control plane and data plane (e.g. DoS by creating lots of LSPs). Big section on SP security issues. (Scope does not include enterprise.) Procedures/protocols for SPs to protect themselves. e.g. hiding TTL. Whole section on inter-provider security. Had comments saying it's a good doc, but too long. Considering a table with a quick check-list per protocol for best practice. LDP for inter-area LSPs (Bruno) Presented at Prague (IETF67). Two versions since then (as WG doc). Clarifications on problem statement, label mapping, deployment, convergence. Now a stable spec. Mostly editorial changes over last 2 years. Now have an implementation. Ready for WG last call? George - work is complete at this point. My comment would be that if you follow industry forums, my own contribution last July etc. there are now 5 different proposals in this space. Some do a better job than others. Do we want to send it all forward piecemeal, or do we want to come up with a solid recommendation of how to proceed (though we may proceed in more than one direction!) Rob Rennison (ECI). We implemented this. Easy to do. Dave McDysan - this only solves part of the problem (signalling). Not fault detection etc. Need more rapid fault detection as well as this. Need that in the solution space. Loa - how many think this is ready for last call vs wait? about equal - and not many people on each. So need to keep going on the list... Bruno - there are 2 families of soln. (1) keep label space flat. (2) introduce some kind of hierarchy. Both are valid, so let's not pick one over the other. didn't see any negative comments on this as an implementation of the "flat solution". So perhaps we need to work separately on solutions that introduce label hierarchy. George - clarification that Bruno's is the only one that keeps things flat. Chairs will poll list if this is ready for last call... IP mobility support using MPLS and MP-BGP (Oleg) Problem statement. Key is to avoid the "triangular routing" in mobile IP. Existing models all have triangular routing. Would like to ask whether there's a way to integrate L3 mobility management control plane with the MPLS forwarding plane to get optimal routing. Want to restrict the set of nodes participating in mobility management to edge nodes. Want to restrict it to the nodes in the forwarding path for the traffic in question. Needs to be scalable etc. The proposal is based on a stacked mobility label that integrates L3 mobility management control plane with MPLS forwarding plane. So associate mobility label with address of mobile host, or set of prefixes served by mobile router. the solution should be independent of mobile IP. Proposing mobility support function in LER. Will integrate with existing MP-BGP control plane. Could be required to indicate priority. Solution will give optimal traffic delivery and support IPv4 and IPv6. Gave overview of architecture. Edge nodes run MSF and integrate to RAN using L2 grooming. Key issue is how to efficiently update the network. MP-BGP is proposed. 4 different update methods. Traffic delivery based on label stack. inner label lookup used to send traffic to mobile end-station. Willing to consider other models to MP-BGP. Aware that people are concerned about MP-BGP scaling for this. draft is here to solicit comments, not to become WG doc. So want to update based on those comments... Loa Q - is this in charter? George - all the IANA registry requests are for things that are outside the control of MPLS. This is much wider in scope than MPLS. Impacts BGP more than MPLS in terms of scalability etc. Andy - the reason we brought this here was to get discussion. So don't need to talk about charter changes. want WG comments on MPLS aspects. Loa - not proper for the WG to discuss anything just because we're not asking for WG status. All discussions must be in context of WG charter. So I want to discuss here now, but if we want to bring it back let's address the charter. George - much easier now to get charter changes, but still a long process. Andy - want comments either here or offline. What do people think? Can they improve it? With regards to BGP WG we don't yet plan to do this there. Chose MP-BGP for now, but willing to choose other models. The key is using the label stack, not how we signal... Igor - Why do we need a mobility label? You could just advertise bindings of PE to customer prefixes. So just like l3vpn with more updates. Oleg - 2nd label is there to prevent set-up/tear-down of LSPs. So mapping IP addresses to inner labels. Igor - Exactly, that's just like l3vpn. Oleg - Making use of topologically-driven full-mesh of LSPs similar to L3VPN. So full mesh is there between all LERs. Igor - Not clear to me how this is any better than just using l3vpn. Oleg - Advantage is that there's no LSP processing other than by edge nodes, so scales better. Igor - Exactly. just like IPVPN. Oleg - If we use MPLS VPN can use VPN label. MPLS VPN label may not be used. The mobility label serves to identify the IP address. Eric - The draft is puzzling. The only interesting problem is how do you constrain the distribution of the info. That's why mobile IP was invented. You seem to have this big framework, and then a little slide saying "and here's the hard problem we don't know how to solve". Oleg - The label distribution issue is obviously much harder with mobility. Eric - This is similar to other problems we have. Lots of crazy ideas going around. Too easy to say we have a framework and just say "we'll do what we do now but make it scalable". Ross - (as routing AD). I understand you don't plan to progress this in this WG for now. Good to discuss here though, so that it is discussed before charter changes etc. Can discuss later as to where we take it. Oleg - No argument - our feeling is that triangular routing will be compounded as mobile-mobile comms increases. The penalty gets linearly worse as network diameter increases. results in increased delay and jitter. Jitter is key. Other things that are architecturally important are bringing the MPLS closer to the RAN, but not bringing integrated mobility management with it. So need that. Loa - need to stop there. So after this meeting: 1) have discussion - mostly driven by authors - on where we do this work. 2) accept comments on technical content until we decide where the work goes... LSP Ping TLVs - Adrian The goal is to help future-proof extensions to LSP Ping Currently, types less than 32K are mandatory. Must process. Those >= 32K are optional and if not supported must be ignored. Are these sufficient for forward compatibility? Will procesing rules hamstring us? For example what if we want a new one that is critical at egress but not at transit. So don't want to upgrade transit nodes. Can't do that with existing rules. So can we get more future proof rules that remain backwards-compatible and don't use too may bits... Draft proposes 4 sets of rules (2 bits worth): 1) mandatory 2) mandatory at egress/optional at transit. 3) optional 4) ignore the entire msg if TLV unrecognised. Could do similar rules for sub-TLVs. Want to get community input. Want to talk to other implementors of LSP ping. Want to agree those 4 rules. Want to move forward quickly. Various drafts are using LSP ping and defining new TLVs. so want to use new allocation rules from the start. So want WG status/last call ASAP. Vach - what if we have a new operation that is mandatory and want to bump the version number up? So for v4 of LSP ping this TLV is mandatory. That's not in there - so can we do it for future proofing? George - my understanding is that bits are outside the codepoint. So if you go to a new rev you can say is now mandatory. Vach - how is that backwards compatible? What's the point of the version numbers? George - so now you say "anyone outside this version number isn't playing the game". So a bit like v4 vs v6. Aim is longer-term survivability, not future proofing. Yakov - we need to answer Q of whether codepoint or version number plus codepoint defines TLV. Eric - what about "this needs to be known by interior LSRs, not LERs" or "this needs to be known by ABRs only". actually I think this is over-engineered. Once you start categorising node types it gets complex. Scott - maybe I'm missing something What's the "throw the whole message away" there for? Seems bad to have purposeful black holes. Kireeti - today we have nothing in that category, but we might find something. George - to respond to Scott the reason for that model is for things like multicast ping. If you add a new whizzy feature may not want 100s of nodes sending you a response asking what the object was. Scott - FWIW v6 has modes for how to notify errors to cover that exact situation. Kireeti - I agree with Eric! Different codepoints for egresses worries me. Nice idea overall, but the 2 bit thing seems too specific. Not sure why you're stealing a code-point for egress. Perhaps we should have "mandatory for everyone", "mandatory for some" - and then a way to identify the "some". Might say "what if it is always mandatory but not for everyone"? So with no sub-TLV is mandatory for all. With a sub-TLV is not mandatory for those identified in the sub-TLV. So instead of solving today's specific problem we get something more general. Adrian - how much do we need to worry about backwards compatibility? Already stolen a bit. Either we go with that, or we invent something new that breaks backwards compatibility. Kireeti - I think it's important to work on backwards compatibility. But if push comes to shove can bump the version number. But enough implementations out there to make backwards compatibility a *very nice to have* (not a must). Eric - I was thinking something similar to Kireeti. Only issue is you at least have to understand the TLV that identifies whether you're in that class. but there are other types of categoriation so we need to be able to support that. Loa - Adrian, you say you want to progress quickly, but you're not asking for WG status. Adrian - as a WG chair I hate it when people ask for WG status. Is WG chair's call... Loa - is it ready? Adrian - WG seems very interested... LSP trace over MPLS tunnels (Nitin) Presented at last IETF but have increased scope and beefed up security section. Overview of problem - how do we trace hierarchical LSPs? So gave example of this. Issue that routers in hierarchical tunnel don't know the FEC, and that ingresses don't know why getting responses from nodes in those tunnels. So how do we make this work? Solution - very simple. node at head-end of hierarchical tunnel tells head end about tunnel and tells the ingress to push the FEC for it. All very similar to data plane ops where labels get pushed/popped. Problem (2) - how do we trace stitched LSPs? Solution - similar to previous one. But instead of FEC push now do a FEC stitch. So stitching points send stitch info back to head end. So basic model is that ingress gets info from nodes which are stitching or putting traffic into a new tunnel. Can send a nil FEC as well if you want to hide stuff. Plan to deprecate the downstream mapping TLV as it is not extensible. Kireeti has accepted responsibility. Solution is a new TLV that has sub-TLVs so you can add more. Of course the draft needs to explain how to deal with old/new TLVs. First half of TLV is the same as the old one, Then have sub TLVs for variable length stuff. so old bits have become sub-TLVs. But new sub-TLVs too for stack changes (push or pop). Can we get WG feedback? And are there other issues (to MPLS OAM) that it can solve? And can it be a WG doc? ??? - in example of RSVP tunnel inside LDP LSP what happens if the implementation treats the tunnel as a virtual link? Nitin - if it's a virtual link the LSP ping echo request will never go inside the tunnel (back to the two options - trace inside the tunnel, or don't). Don O'Connor - is this to address multi-provider OAM George - Not on its own. There's other work going on. All these different bits of work. This part is a step towards the inter-AS case, but doesn't solve it in and of itself. Trying to get pieces together. Don - Before it goes any further needs stronger section on inter-AS. George - There's a separate inter-AS draft. Jerry - They need to be related, or there needs to be a section. Nitin - There's text in there. Kireeti - Don't want to limit to intra-AS. Don't need requirements doc. This is a toolkit. Anyone else can write that reqs. George - These are examples. People have gone out and done stuff we didn't expect. Need to change OAM to reflect that. Loa - Stop now and take rest to the list. Way out of time... Head node protection mechanisms - Cao Wei Issue is that the head-node is a single point of failure. Showed model - Main Head Node (MHN) and Backup Head Node (BHN) idea is that BHN builds backup LSP to nodes downstream of MHN and monitors MHN status. Only sends traffic if MHN fails. So MHN assigns BHN. Use path message to sync info between MHN and BHN. Use existing mechanisms as much as possible. So use FRR mechanism - thus it looks like a link failure to the MP. New head node protection object. Only applicable to certain topologies. Also issues as to how BHN detects MHN failure - may be vendor specific. Still issues to address. so how does MHN pick up again when it comes back? And what if things change while on the failure path. Ben Niven-Jenkins - How does vendor-specific failure detection work in a multi-vendor network? LDP end-of-LIB (Rajiv Asati) Motivation is that we want to know when a peer has finished advertising labels for a FEC type. Issues such as IGP/LDP sync (how do we know when we're synced), LDP GR (how do we know when finished), typed wildcard FEC (how do we know when we've had all the response?) Solution is straightforward. New status code for LDP notification. Also a new LDP capability. Notification has 2 pieces of info: 1) status TLV for end-of-LIB 2) typed wildcard for FEC type. To help prevent a proliferation of new LDP capabilities, we made this one generic. The end-of-LIB capability defines and uses an "unrecognized notification" capability. This can used for other apps. Also clarified what you do when you get something you don't understand. Added a new section giving examples and timeouts in case notification is missed. Would like to make this a WG draft. Loa - who's read it? lots of people so taking to the list. Out of time for the meeting so we're done... one extra presenter - but he'll send to mailing list.