MPLS Working Group Meeting in Seoul Monday, March 1 at 1300-1500 ---------------------------- Chair: Loa Andersson Note takers: Giles Heron and Rahul Aggarawal. Thanks! 1. Agenda bashing ----------------- The agenda was accepted as published. Slides: mpls-agenda-seoul.htm 2. Working group status - Loa Andersson --------------------------------------- bunch of docs on RFC editor queue. In good shape. Most docs waiting for refs, but relatively few. Waiting for IANA codepoints in some. GMPLS routing is holding some of this up. It's depending on a whole bunch of stuff. The rest should be easy to get through. RFC Editor found that for FTN MIB two of the refs weren't referenced. MTU draft and IP/GRE are with the IESG. Problem with MTU is that there are no known implementations - need implementations to go to standard track. May be that we can do experimental first then move to standards. IESG has sent Fast Reroute and LDP PING back to WG for updates. OAM requirements author has asked for WG last call. Loa waiting for OK from authors to send various others drafts to IESG or WG last call. OAM framework - Tom Nadeau and Dave Allan editing it. Plan is to publish an first version I-D soon. The authors has agreed on an table of content and started fill in text. Slides: Working group status 3. RSVP-TE attributes - Adrian Farrel ------------------------------------- The aim of this draft is to address shortage of bit-flags in session attribute object. The attribute flags object has been variable lenght to make it more extensible. RRO subobject allows each node to say whether it supports a bit and whether it acts on it. An RSVP-TE attribute is an LSP attribute, not a session attribute. This ID is stable and referenced by other drafts. There is a temporary registry to track allocations until this goes to IANA. The attribute per-LSP os of value in Resv and might be used for P2MP. It is easy to add and will be optional. The plan is for one more iteration of draft in March (with per-LSP Resv added) and then document implementations, where are a couple started. after that it will time for working group last call. 4. LDP graceful restart for planned outages - Ina Minei ------------------------------------------------------- The goal of this ID is to do graceful restarts, but only for planned outages (e.g. s/w upgrades). It is not within the scope of this ID if restart is ungraceful in other cases. Graceful Restart parameters are negotiated at session establishment. So one will have to flap sessions to change them. The aim is to make it possible to run in a"no GR mode " by default. When a planned restart takes place and the session is to be closed, one will be able to configure that at the next restart this will be done in a graceful manner. This will be backwards compatible with graceful restart RFC. To make this work we need a new optional parm (GR data TLV) and to send this with shutdown status code. The new TLV Carries reconnect time for when it comes back up. A scenario is to tell neighbours that the LSR are going down, but tell them to wait long enough to allow for the restarting LSR to come up gracefully. Neighbours will then wait until the LSR has come back up. The restart box will be graceful for the planned outage, but ungraceful after. This could be done without specific configuration. The discussion focused on how useful this would be. Questions on whether it wouldn't be feasible to always do graceful restart and whether there is a way for to check if neighbors support this were asked. Authors said that there is no need to be able to check if a neighbor supports this since the planned restart will be initiated by the operator and that this could be a way of introducing graceful restart in a controlled environment, before implementing "normal" graceful restart network wide. Discussion to be continued on the mailing list. 5. Requirements for Point to Multipoint extension to RSVP-TE - Seisho Yasukawa ------------------------------------------------------------------------------ The work orignated in an effort to put together requirements for TE MPLS multicast. This will for a basis for evaluating solutions in this area. Since last meeting input from service providers has been added to the requirment specification. The ID is now very stable and the goal is now take the ID to working group last call after some minor updates. Major changes since the previous version: 1) Now a WG doc and added SP and CCAMP authors 2) terminology 3) scenarios 4) make-before-break 5) Added scalability and backwards compatibility. Remaining Issues: 1) need some extra terminology 2) do we address more sophisticated functions. Authors would rather defer to another doc. 3) Intention is re-spin and then go to working group last call. 6. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels - Alan Kulberg ------------------------------------------------------------------- This draft is backwards compatibility with existing RSVP-TE LSPs, does simultaneous prune and graft and allows for an implementation based on P2P mechanisms and smoth migration because it doesn't need wholesale upgrade of network. It will set up multiple P2P LSPs from sender to a single leaf, and then from each branch node to a single leaf. The association object is used to associate them together and form P2MP LSP. There have been some changes since the previous draft: Branches are encoded in secondary EROs (SEROs) up to the branching node, after that encoded into ERO at the branching node. Only the brancing nodes need to process the SERO. The association object allows parallel LSPs and does make before break on P2MP LSP. The opinion of the authors is that this draft satisfies the requirements. Issues: There are two different solutions drafts for TE P2MP LSPs. The chairs and the meeting strongly encourage the authors for both need to get together and converge on a single soultion. Charter milestone is Nov 04 for WG document to be submitted. Edits will be done soon and submitted. Welcome WG feedback on the email list. Want direction here as to how to get solutions merged together. Discussion were on capabilites of the solution. e.g. Fast Reroute in case of node failure. Authors agreed that this should be added. The choice of RSVP-TE as protocol for TE P2MP MPLS were also challenged, but this discussion was defered until after next preentation. 7. Establishing Point to Multipoint MPLS TE LSPs - Rahul Aggarwal ----------------------------------------------------------------- This draft address the problem of introducing Traffic Engineered MPLS p2MP LSPs into the data plane with minimal changes to current RSVP-TE. It is optimized for a high volume of multicast. It uses P2P LSPS as building blocks. It leveraging the existing Control Plane model, as RSVP-TE support multiple LSPs per session. One design criteria has been simplicity of protocol and implementation. MPLS multicast label mappings set up at the merge nodes. The Source PE (SPE) initialises P2P LSPs to each Remote PE (RPE) for P2MP LSPs. common session object but distinct sender templates and PATH messages (P2P TE ERO in each PATH). Each RPE initates a Resv. Upstream node does RSVP-TE SE style merge. SPE gets one Resv per RPE, but merge/branch nodes have set up the label binding. Makes it very easy to add new elements without impacting the existing tree (could be significant churn with multicast). Enhancements since 00 draft: identifiers for constituents cleaned up supports secondary P2MP LSPs (as this is common for P2P) Non-adjacent signalling. Make before break. Fast Reroute. LSP hierarchy. Authors believe solution is on a par with P2P LSPs - and reuses their machinery. It lets you signal different attributes for each P2P LSP - so in inter-domain case can give different behaviour for each exit point. Aim is to move to WG doc. Discussion were on the realtive merits of the two solutions proposals. This discussion concluded in that issues with both proposals should be sent to the list and the there seeems to be good reason to continue investigating ways of merging the two proposals. It was also pointed out that there is work in other groups on multicast, e.g. extending PIM. In response to that it was said that the work specified in the two draft are for Traffic Engineered LSP only. Nevertheless there is a need to coordinate this work with the multicast working group(s), at least when it comes to non-TE. 8. Nexthop Fast ReRoute for IP and MPLS - Naiming Shen ------------------------------------------------------ The goal for this draft is to solve the problem of Fast Rereoute for traffic in general, not just TE LSPs. LSPs, regardless if they are LDP, TE, IP or IP multicast is protected. There are several known approaches: 1) IGP Fast Convergence - when a link or node failure is detected flood/process this information faster than other IGP information. This enables the whole network to converge faster. 2) MPLS-TE Fast Reroute 3) Pre-Computed alternative next-hops. Based on IP (typically IGP) information. Download alternative paths into forwarding plane and switch onto that when there's a node/link failure. 4) Next hop fast re-route. Use MPLS LSP as an explicitly routed tunnel to reroute general traffic in case of node failure. All four types of traffic have an IP next-hop. An explicitly routed tunnel is used to protect the next-hop. Use this to route to next-hop node or next-next-hop. Protection LSP is unaffected by routing changes as is explicitly routed. Could equally do this with Frame Relay etc. Reason for doing it with MPLS is because modern routers support MPLS LSPs. Can either use one tunnel to protect mix of traffic, or one tunnel per traffic type, any approach is possible. The uniform in itself is a benefit. Don't need one mechanism for fast reroute for TE and another for IP. Tpo achieve this we need an new RSVP object - bypass next-hop. It is used by ingress node to inform egress of what you're trying to protect. For link protection is next-hop, for node protection is next-next-hop you've learned through some other mechanism. The major application is multicast. Need to modify the RPF check. We need to request a C-class number from IANA for bypass nexthop object. There are also drafts on node-protection for LDP and for PIM. Too early to adopt this as a working group document, the discussion will be continued on the mailing list. 9. Discovering LDP Next-Nexthop Labels - Enke Chen -------------------------------------------------- This is an LDP specific follow-up to the draft discussed previously. Normally LDP nodes only know bindings for adjacent peers. To do node protection next-nexthop labels are needed. The next hop label discovery is build on two capabilities. - the ability of a node to signal its interest in getting the next-nexthop label mapping info and the ability of the node that receives this request to advertise the next-nexthop information - the use of the status TLV to carry info in notification message (saves inventing a new TLV) and the use label TLV to carry next-nexthop info in label mapping (consists of label/router-id pairs of next-nexthop nodes). Loa (chairman's hat off) - we do FRR. Fine. It is one of the key element in TE. Fine. We have RSVP-TE as TE tool. So why start doing TE with LDP at this moment? We closed CR-LDP about a year ago, and it is not our intention to revive it. Authors responded that LDP is widely deployed today. Fast reroute makes sense in this kind of deployment. RSVP-TE is already available sure. If you are using LDP for L3VPN then don't need to turn on RSVP-TE for Fast reroute. BTW we are not trying to do TE for LDP. Just trying to protecting traffic. Questions were asked if tLDP already gives give you what this draft tries to accomplish. The discussion on first draft will contiune on the list, it makes sense to include this second draft in that discussion, since they are closely related. 10 .Multiprotocol Label Switching Pre-emption - Adrian Farrel ------------------------------------------------------------- The issue were brought up in Minneapolis and it was agreed upon that there are differnt interpreations on how to preeemption in different RFCs, as well as various interpretations of what people *want* to achieve. In preparing the draft the author have polled for requirements. The discussion has been very limited on the list, and some off-line. The requirements are - that we have known and understood procedures for soft/hard pre-emption, - that these procdures are backward compatible - that it possible to tell what is soft vs. hard preemption. Author asked if there is an intrest to continue this work and several people said that there is an contiuned interest. Issues: Need to clarify GMPLS - especially for soft preemption. Question as to whether existing soft preemption draft will now be redundant. Not going to address rights and wrongs of implementations. Plan: Will clarify GMPLS in march. Last call April. Not a big deal - just an error code. Adrian - Loa, would you like it to be a WG draft? Loa - asked you to do this because I care, so we need a working solution with >1 implementation. Not been asked if we should make this WG doc. Probably come back to it once you've done a re-spin. Dimitri - can we fix a timeline for this. If we don't find a solution soon will have workarounds that people find. Would like it solved ASAP. Do re-spin soon and discuss on list. Loa - Adrian promised re-spin in March. Take to list then and discuss if is WG. 11. Meeting closed ------------------