MPLS WG minutes - IETF 69, Chicago, July 23rd 2007 --------------------------------------------------------------------- wG Status (Loa) --------------------------------------------------------------------- 1) 4 RFCs since last IETF + one on MPLS/GMPLS change process (RFC4929 - as BCP129). Will be liased to other orgs. 2) ICMP draft in AUTH48. 3) 3 drafts in rfc-ed Q - Ina to respond to RRFC editor for LDP spec. (3036bis-04). Need security section for LDP experience and survey drafts. 4) 1 draft in IESG review 5) Many WG drafts - 2 on agenda. LDP typed wildcard gone through last call. Issue of refs to old LDP spec not new. LDP capabilities - authors want WG last call. 6) 2 expired drafts (Loa's fault for letting them expire) 7) 1 doc accepted as WG but not yet issued (decraene-mpls-ldp-interarea). Liasons (Loa) --------------------------------------------------------------------- incoming liason from ITU-T SG15 on G8110.1. The main discussion Will discuss be in the PWE3 wg, mentioned here only to point to the upcoming discussion. Please read and take part in discussion (the liaison concerns the T-MPLS/MPLS relationship) The IETF will send a liaison to the ITU-T on the use of MPLS codepoints in the T-MPLS specifications. T-MPLS background (Stewart Bryant) Slides: 01-TMPLS background.ppt --------------------------------------------------------------------- T-MPLS from SG15 Q12. Series of G8.1xxx recommendations. Liased to IETF post consent. Basically the T-MPLS data plane is an Ethernet PW over MPLS over Ethernet. OAM is extended from Y.1711. Currently T-MPLS is using statically configuration by a central NMS. ITU-T is looking at a control plane. Using a formal language (proprietary to SG15) to describe how MPLS PWEs work. ITU-T SG15 say MPLS and T-MPLS are disjoint layers - goal is to use existing kit to carry T-MPLS using MPLS codepoint. So no need for new codepoint as no intention of interop between higher layer MPLS and lower layer T-MPLS. But at last ITU-T meet there was a specific contribution on interop. Liason statements sent expressing our concern. IETF concerns are that T-MPLS or its extensions may break MPLS or a future extension of MPLS. Key issue is shared codepoints with different specs - may well collide. Experience tells us that scoping rules never stay fixed and limits always grow. We may have massive interop and interworking issues down the road. plans to implement other sorts of PWE that duplicate IETF work (so not just Ethernet over MPLS, but many other types too). will be more discussion in PWE3 this afternoon (most liason to/from there). So come to PWE3! Loa - I've stepped down as IETF liasion to ITU for MPLS issues, Stewart Bryant will take over. Ross - would like to thank Stewart for being willing to take it on. Ross - meeting on Saturday between senior ITU reps, IAB, IESG plus some extras (e.g. the IETF to ITU liasons). Various issues discussed - including T-MPLS. Subsequent to the meet IESG met on Sunday morning. Major chunk of discussion was on T-MPLS. This morning the IAB and IESG discussed T-MPLS, MPLs and GMPLS over an early breakfast. First time I've seen the IAB and IESG in complete agreement on anything! Quite definitely this issue has helped to foster co-operation inside IETF. Planning to write a document explaining our understanding of the ITU requirements, of MPLS, T-MPLS, and of how they may interoperate or clash. One part will be our concern about T-MPLS using the same data plane and control plane codepoints as MPLS and GMPLS. Document will be published as an Internet Draft intended to become a RFC. But to get to RFC needs to be discussed in IETF so will take a while to produce. In the meantime the intent is to send liason to ITU-T expressing our concern about T-MPLS using the same codepoints. We know WGs have already done so, but this will be from the IAB and IESG and their chairs (IESG chair is IETF chair). The maim point in this liaison will be a request that they use different codepoints. We plan to send the liaison this week. Generally takes longer to do that (last call typically takes 2 weeks or longer). Wewill send it quickly and then do work on a more detailed document (in a spirit of co-operation betwwen the two organizations). That document will put down our concerns about having two set of protocol work using the same codepoints, and the likelihood of collision based on future work or config errors. George - what level of the ITU is this being sent to? Ross - since is coming from top leadership of IETF think should go to top leadership of ITU-T. Would make sense to send to SG15 and all layers of leadership above that. Yaakov - we need to send to SG13 as well as SG15, as they're working on it too. Mark Townsley - needs to go above as we've had WG to WG liason already without much effect. George - I wrote last liason and got smiles but not much action, so agreed we need to go to top level. Ross - I don't know where/when next ITU-T meet is, but if I can go am happy to go and to tell them of our level of concern from IAB/IESG. Would like to know of IETF has the same level of concern (in general). Italo Busi - next ITU-T meeting is 10-14 Sept in Stuttgart. This is an Interim meeting of Q12/15. Yaakov - that's an interim meeting, not leadership meet, so not right place to go. P2MP bypass tunnels for P2MP LSPs (JL) draft-ietf-mpls-p2mp-te-bypass-01.txt Slides: 02-P2MP-FRR-WG01-v2.0.ppt --------------------------------------------------------------------- There are issues when using P2P bypasses to protect P2MP LSPs, e.g. inefficient replication. This draft specifies a P2MP bypass to address those issues. The draft achieves scalability of label stacking whilst avoiding inefficient replication. During failure a tunnel might use 1 or more P2MP bypass tunnel(s) towards set of merge points. The Inner label repreents backup LSP label, while the outer is bypass label. To avoid replication the PLR needs to assign the inner label to all MPs using upstream assignment. Changes since this document were last discussed in the working group: 1) The draft wa adopted as a WG doc in May. 2) The no PHP behaviour has been clarified . It is not possible to do PHP as a context identification needed at the MP. The no-PHP can be used using Zafar's draft. 3) Reversion must entirely rely on FRR RFC (RFC4090). Ther are two modes - global and local. 4) A new section on PLR location has been added. May be local with respect to a failure or remote, that is 2 or more hops upstream. 5) To enable backwards compatibility a new section on how to use a mix of P2P and P2MP bypass LSPs has been added. 6) Link protection procedures has been clarified. 7) Bypass tunnel selection options has been clarified. 8) A section on partial protection has been added. 9) General rewording etc. for clarity. The discussion in the meeting focused on bullets 5-8 above. 1) P2P/P2MP mix. P2P use RFC4875 procedures, P2MP use this doc. No need for upstream label assignment in P2P case. So the propoposal is backwards compatible with LSRs that can't support upstream assignment. 2) P2MP selection options. There are several options, there may be an exact match to set of MPs. There might alos be a superset (in which case leaves which are not MPs will drop traffic), or multiple tunnels. Depending on the type of optimization that is sought for control plane/ data plane there are different tradeoffs. This leaders to choices that have an impact on operational complexity. 3) Link protection. The technique specified in RFC4875 relies on a P2P bypass tunnel. In some cases the P2P bypass tunnel may share a link with another part of the P2MP LSP. Optional procedure allows the use of P2MP bypass for link protection; originally the technique was designed for node protection. It is possible to use P2MP bypass tunnels to protect all MPs downsteam of a PLR; even if they are not immediately downstream of protected link. If there's a failure forwarding traffic will stop on the protected LSP and the bypass LSP will be used. 4) Partial protection. Partial protoection is a new feature in this rev - so WG feedback is needed. The draft covers the case where it is not possible to find a P2MP bypass that covers all MPs. This may happen - e.g. if there are bandwidth limitations. What happens in this case is that when the FRR is activated some leaves won't receive traffic. Default procedure would be that LSP is either fully protected or not protected (by FRR). This gives the option to have partial protection. The draft includes procidures that allows partial protection in the case where full protection. Need feedback. To conclude: 1) need to align this draft with the upstream assignment architecture draft. PLR should assign upstream labels from a single label space. 2) need WG feedback 3) will submit new rev before Vancouver. Zafar - The P2P backup can be considered as an S2L within P2MP backup. JL - can't do that in case where one MP isn't upstream capable. So can't consider the pair of bypass LSPs as one. George - one's doing PHP with no context label, and the other is doing no-PHP and using context. Zafar - Is this, non-upstream capable attribute, advertised as node capability in IGP? JL - there's an RSVP-TE attribute and it's described in the upstream label draft. Dimitri - what you're doing in the link failure case means you're disrupting traffic for a branch that shouldn't be affected. Is it a requirement not to interrupt branches that should not be affected by such failures JL - to mitigate your comment will only lose or mis-sequence one or two packets as you update your FIB. Dimitri - we need to be aware of tradeoffs we have (and document them). JL - we'll do that in next rev. P2MP LDP (Ice) draft-ietf-mpls-ldp-p2mp-03 Slides: Missing --------------------------------------------------------------------- The following changes has been made in this draft since last time it was discussed: 1) Root-Node Redundancy. Similar to MP2MP case. Multiple LSPs to the different roots. Only one root can forward packets. Root selection is out of scope. 2) added capabilities for MP2MP and Make before Break (MBB). 3) MP status TLV. Signals extra info related to MP LSP. May be in label mapping or notification. The TLV is opaque to LDP so only LDP MP needs to look at it. Used for MBB, but can use for other stuff in the future. 4) upstream label allocation for MP2MP LSPs. Uses MPLS upstream draft for context label (for Ethernet interface) and LDP upstream procedures to advertise the label. A diagram clarifying upstream label allocation was shown. There are two 2 labels in a packet - context label and LSP label. Downstream routers look at context and then the LSP label in a 2nd lookup. There is no difference between P2P LSP and P2MP LSP in this case. Upstream traffic diagram - router will create label state for the context and for LSP labels. The router won't see any difference in packets going upstream, or going downstream. No extra labels needed to forward packets upstream. MBB - more detailed in this draft. Noted use of MP notification - used to signal that the LSP has been established. Loa - seems we're getting various drafts using the upstream procedures. Are there any mutual dependencies? Ice - MP2MP procedures are in the LDP draft. But should be in one of the upstream label allocation drafts. Rahul - The first problem is with the upstream architecture draft. This little piece on MP2MP LSPs on a LAN needs to be defined as to where it resides. But if upstream progresses then next step is the LDP upstream draft. Then this draft can use that. Architecture draft must go first. Ice - should we add this to LDP P2MP draft? Rahul - I've got no problem if you want that. But the working group need to discuss this. Yakov just reminded me that we need to progress the encapsulation draft also. Loa - You're co-author on both the architecture and encapsulation draft. What's the status? Rahul - arch draft needs one rev before last call. Loa - how far out is architecture draft's next rev. Rahul - before next IETF. Loa - This is critical as we're getting drafts stuck which can't progress as waiting for other drafts. Rahul - encaps draft is pretty mature. Rahul - I've got one Q on the LAN slides. If there are multiple routers on the LAN and they pick different upstreams to get to the root then what happens? Won't downstreams get packets from unexpected upstreams? Ice - downstreams will only install context for the intended upstreams. So even if the "wrong" Upstream sends packets the downstream will drop them. Rahul - good clarification to add (not that I've read the draft). Bob - does LDP upstream assignment draft depend on LDP capabilities? Rahul - We have several dependies, the MPLS multicaast encapsulation draft depends on upstream label assignment architecture. These drafts need to progress at same time. Then we have LDP upstream assignment draft, it is likely that it need tió be progressed together with the LDP capabilities. MPLS/GMPLS security framework (Luyann) draft-fang-mpls-gmpls-security-framework-00.txt Slides: 04-MPLS GMPLS Security Framework - IETF 69.ppt --------------------------------------------------------------------- Status update. Draft will stay in MPLS WG but be presented at MPLS and CCAMP.Not yet extended to other WGs. The draft been updated before this IETF. The authors thinks it is mature enough to become a WG draft at this time. Why are we doing this work now? Issue is that security ADs and reviewers have been raising comments on drafts. Our goal is to have one document to amerliorate this situation when writing for detailed security section in MPLS and CCAMP drafts. These drafts can reference this document and build on it. We have had various comments on 00 draft, e.g.from Rich (Graveman), Sam, Adrian etc. A general comments has been that this is important work and the draft should be accepted as a WG as son as possible. We still need input as to whether scope is correct or should be changed. The intention is not to say e.g. that protocol A is better than protocol B - but to document the nature of different protocols. We have lots of stuff on DoS in document. You can't entirely prevent DOS attacks, but it is possible to greatly improve the situation. So there is issues of e.g. line-rate filtering and access restrictions. There was one comment that the satement made on encryption in the draft is not currently true, and it hhs been modified. But we may not need encryption but just integrity checks (much less expensive). We now see big issue on key management, this was missing in the 00-draft. The document needs have an extensive treatment on key management - or you can't do integrity checks. We've also had comments on e.g. OSPF and ISIS. We're in the trusted zone here, but the issue is how you prove it, what you are allowed to do if inside/outside, what you can assume that everyone does inside the zone e.g. do all members do same per-interface security? The document also gone through minor structure changes. We need to find the right tradeoff between what goes into this document and what belongs to the specific protocol documents. It may be that the individual protocols (e.g. RSVP-TE) need to address their own specific security considerations. Dimitri - did you identify key security issues that exist in operating MPLS networks. So then you can pick those issues and then go into the details. Otherwise you end up with very broad scope. Luyann - good comment. JL did lab tests - e.g. what happens if don't have good security and unauthorised signalling comes in. Router CPU gets hammered. So these are practical considerations. Dimitri - would be interesting to see what has highest priority to user community at large. Luyann - do we need examples from e.g. L1, PCE, etc. Loa - who has read? Who thinks is WG-ready? Seems to be the same hands, but will ask the list to confirm... LSP trace over MPLS tunnels (Nitin Bahadur) draft-nitinb-lsp-ping-over-mpls-tunnel-00 Slides: 05-draft-nitinb-ietf-chicago.ppt --------------------------------------------------------------------- This a recently recently submitted draft. Simple example of LDP/RSVP. May or may not wish to allow tracing of RSVP-TE LSP from the LDP layer. So you may see LDP path, or full path including RSVP hops. In former case may be unable to see why the LDP trace has failed if the inner LSP is broken. Also may have issues e.g. where RSVP-TE LSP is up but LDP LSP is not taking the right path (control plane/forwarding plane mismatch). Current problem is that the RSVP-TE only hops don't know anything about the LDP FEC - so you'll get an error (even if the whole path is up). George - there is info there, and it is workable with the existing draft. Your draft also adds some new functionality, but need to agree if it is needed. Nitin - as George mentioned there may be ways to skip control plane validations, as you know the ILM. But RSVP-TE only node will only look at outer label. So can't do control plane validation. George - that statement is correct. Nitin - we're solving that by having full control plane validation. But don't want to make it a requirement that the intermediate routers expose all info (so want to allow hiding). How does it work? Ingress LDP/RSVP edge can tell upstream that it has a FEC stack. So ingress can then use that FEC stack when sending to RSVP-TE only nodes. So those nodes see the correct FEC and can do full control plane validations. Egress LDP/RSVP edge will tell ingress that it is the egress for the RSVP-TE stack. So now can just do LDP trace to downstream nodes beyond the tunnel. So basically getting intermediate routers to provide info to the ingress on the start of new tunnels (but can choose to hide that). Much better than having no validation. Most logic is at the ingress application to do the trace. TLV changes proposed (building on LSP ping). New TLV is added (Downstream FEC stack). Used to associate to a DSMAP. The authors want to have feedback, and opinions on if this should be a WG doc. Tom Nadeau - have you thought of solving this using remote ping/trace? Nitin - yes. Could do that if you encounter a problem? Tom - if you implemented code to understand responses correctly then you could understand if there was a problem and then choose to do remote trace. Nitin - but you wouldn't have the correct FEC stack from the intermediate router so can't catch that. Kireeti - this is a specific problem that this technique solves, but also solves more general problems (e.g. end to end LSP that is stitched together, e.g. RSVP-TE to eBGP to LDP from inter-AS VPN). So yes, you can solve some problems using remote ping/trace, but not all problems. Nice thing here is that the FEC stack is doing what the LSP is doing (pushing/popping labels etc.) Ina - this is an enhancement for trace. Trace is diagnostic tool and with this the diagnistic capabilites of trace may be approved. We want to have as much information as possible. If we ignore e.g. an error in RSVP-TE LSP that defeats the purpose of trace being an accurate diagnostic tool Vach - another case is bypass tunnels. Why not solve that also here? So extend what you have to cover the case where the PLR knows it will use a bypass. We do what George is saying, but can we extend this approach to cover bypass tunnels. George - I believe this approach would if I understand it correctly. Kireeti - yes it would (in the control plane) but the problem is the data plane will go on main path unless the bypass kicks in. George - this is data trace, not control plane, so don't see use for that. Adrian - rather concerned at empty security section. Confidentiality matters. Need the ability to hide tunnel info from nodes outside the tunnel. Nitin - can use nil FEC entry to hide things. Adrian - so say so in the security section. George - nil FEC is equivalent to correctly implementing the existing draft. Loa - who's read it? Many hands. Who thinks is ready to become a working group document? Not as many. Nitin - we will take this offline. Loa - I won't ask the list, but will wait for a new revision with input from George, Adrian etc. Aggregated IP FEC (George) draft-swallow-mpls-aggregated-fec-00.txt Slides: 06-Aggregated-IPv4_FEC_IETF69.ppt --------------------------------------------------------------------- This draft covers ground that is similar to what is in Bruno's draft. Bruno is not here, but back in France with new born twins! The goal is to achieve better scaling in terms of IGP and LDP state. Today you need /32 FECs for all L3 VPN PEs when using LDP for tunnel labels. So the way people do that today is not to summarise those /32 prefixes at area boundaries. This results in lots of routes and labels. We're victims of our own success as MPLS networks grow. So this is good news!!! A new FEC type is specified. The semantics are the same as today, but indicates that next label is an unaggregated label for a /32. The issue is that you don't necessarily know which ABR will get a packet, so each ABR needs to know what that label means. De-aggregation label is based on masking the high-order bits and adding 16. This will work with a /13 or longer prefix. The algorithm ensures that all ABRs have the same understanding of the deaggregation. The rules are that anyone summarising is allowed to send out the FEC. The label must be non-null (as can't do PHP for context labels). Must be downstream assigned and ordered. LDP labels for specific routes from area that you're the border of. Context label points to the de-aggregated FECs (or to a standard /32 FEC). Resummarisation is possible but not very feasible. It would involve translating each label individually. Would encourage you all not to pursue that! One drawback with this solution is that it need 2 labels at the ABR (might cause some platforms may be slower). Another drawback is that next-hop tracking is lost, but hoping to come up with a solution for this by next IETF in Vancouver. Bruno's draft doesn't need 2 labels at ABR. Also in Bruno's draft you get to see the label withdraw so can use that to e.g. change the next hop. However, this draft reduces label distribution and preserves LFIB space (unlike Bruno's draft). Also keeps LDP and IGP co-ordinated (again unlike Bruno's draft). The goal is not to stop or replace Bruno's draft. Ina - this draft causes permanent VPN blackhole if there's a failure to that PE. Seems also that it won't work for v6. So maybe you want to look at that. George - Q is will algorithm work for v6? Ina - true nobody is deploying v6 router IDs yet, but why restrict it? George - Q is whether I'd need to change algorithm for v6? e.g. toggle bits in other parts of address range. Ina - also draft doesn't show what you'd do with more specifics, e.g. what happens if you punch holes for some /32s. George - not highlighted. No need as will always pick most specific address. Kireeti - I have a comment/question. Is this first step in accepting label blocks as a valid technique? George - difference is these labels don't come from global space. JL - actually the hierarchy idea is quite interesting. reduces FIB space. But may have side effects, e.g. lose fast failure recovery approaches etc. So may be optimising CP at cost of losing LDP FRR mechanisms. so need to mention that. George - have thought about that. Right now LDP FRR isn't that mature so is a bit of a moving target. key is that if you had to change ABR the context labels wouldn't change. JL - but would have to merge in another ABR? George - change strategy so instead of going through next ABR would just go to it and rely on the ABR knowing the context label. JL - another point. If I have a network with a /13 or longer prefix I don't need LDP any more. George - I've not proposed that. Scaling in MPLS-TE networks (Adrian) draft-yasukawa-mpls-scaling-analysis-04.txt Slides: 07-mpls-te-scaling.ppt --------------------------------------------------------------------- The starting point for this draft is not that MPLS-TE is broken, but we are looking forward to see where the barriers are. The issue is a PE-PE mesh, i.e. the same it's the old N-squared problem. There is a protocol overhead, e.g. of maintaining state. We became aware of this when we were looking at LSR management. Too many entries in the MIB for the NMS to retrieve. There are potential solutions: 1) hierarchical LSPs 2) something else? We first presented this draft in Dallas (March 06). There are a number of updates including adding Femi (Glasgow University) as co-author. The approach we taken is to look at "simple" but large topologies (snowflake and ladder) to try to illuminate problems, the benefit is that it is simple to model. A "snowflake network" is a meshed core with edge trees. A "ladder network" is an unmeshed core with edge trees. We've looked at flat networks, FAs (hierarchy) and MP2P LSPs. The metrics we have used are: - # of PEs, - # of LSPs per LSR, - amount of LSP state per LSR, - P/PE ratio (cost effectiveness) Conclusions: 1) hierarchical LSPs don't scale as well as you'd expect. Issue is you need multiple layers of hierarchy to get good benefit. Also have major management overhead. How do you manage concentric circles of FAs? Auto-mesh may help, but still major planning task. Issue of OAM degradation. 2) MP2P LSPs. Auto-merging of LSPs, with bandwidth increasing as you move downstream. So great LSP scaling (especially in ladder topologies). But LSP state not as good (more state per LSP). Also issue of traffic disambiguation. So how do you know where a packet came from? New functional controls needed to make it work properly. Next steps: are to polish this and close it off. Would like it to be an individual submission that would attract WG review in last call. Notpushing for WG status, but pushing people to realise there is a real problem out there to be addressed in future. Ben Niven-Jenkins - this work is valuable. Had read the first version but forgotten the content. Do you take account of dual-homing in topologies? Adrian - we don't, but ought to, but it'd fry my brain ;-) Will have a think about it. JP - agree this is good work. Do we need a solution? If you're using MPLS TE to optimise b/w then isn't it safer e.g. to have full P router mesh. So get 80% of benefit whilst reducing LSPs by an order of magnitude. Adrian - e.g. between middle layer in my diagram? Issue is how many P nodes do you have? And do you need to have another layer of meshing? JP - in a particular core e.g. with 1000 PEs have 100-200 P routers. What I'm questioning is do we need to find a solution. We have something that may be good enough. Key may be to protect stitching points. Adrian - as soon as you have a mesh between "edge" P routers then you have a solution. So you've answered your question as to whether you need a solution. JP - so we're in violent agreement. Also want heads-up to WG. We're writing draft on this. In many cases where people have a problem the solution is hierarchical LSPs. What we intend to do is to document all the issues with H-LSPs. If anyone wants to participate see me later. Adrian - to summarise where that's coming from. As soon as you go hierarchical you lose granularity of control. Dimitri - interesting to discuss this. But what's the objective in terms of performance in terms of number of states in network? There is no perfect solution. So if we don't state this we may come with solutions that are totally incorrect. It may be a general question. Are you willing to enforce merging in the multi-area case. Or does the source see the full topology so you're just enforcing a policy? Adrian - those are both good questionss. Looking at the second one first. We have for the sake of understanding where we're starting from looked at a single flat routing area. Breaking into sub-areas or ASes would be an interesting exercise. in terms of objectives we need to do more work. Started with a simple one of "we want to be able to operate a network". Dimitri - There's a question of signalling/routing relationship. Similar to Bruno and George's drafts. Is a scalability issue. Need to check what type of solution we're looking for. Adrian - another objective was to do TE. Dimitri - so is for MPLS-TE only? Adrian - yes. JL - this draft is very relevant and practical. I may have some minor concerns. Did you look at the key issues in RSVP-TE scaling? Is it the number of states, size of state, CPU, memory. with MP2P LSPs you reduce the number of states, but you may have more processing when you add or remove LSPs etc. Adrian - just as with P2MP, the bigger your tree gets the harder it is to modify it. We haven't analysed it, but we have recognised it. Not the same as one LSP. ? - so in a large network you can't have a full mesh of P2P LSPs. Adrian - my experience of telling SPs "you can't do that" is that it doesn't help! SPs want a full mesh of TE tunnels. ? - but there's no solution at this point so going in this direction is dangerous. Adrian - if the decision from this work is "you can't do it" then that doesn't mean it isn't valuable. ? - SPs are facing this even more with P2MP. so would be beneficial to include that. Dimitri - if you plan to continue I'd love to see you look at scalability, robustness etc. Must look at amount of info that's restricting state operation. So look at fate analysis. With MP2P have one state that interconnects all LSPs. Would be willing to help. Loa - would like Adrian to put CCAMP chair hat on so we can agree process around this document. I'm not sure is as simple as sending it in as an individual contribution. Bob Thomas - LDP end-of-LIB draft-asati-mpls-ldp-end-of-lib-00.txt Slides: 08-ldp-end-of-lib-IETF_20070723.ppt --------------------------------------------------------------------- The motivation for this draft is an addressing an oversight in the LDP spec. An LDP speaker has no way to tell when its peer has advertised all its label bindings. It may be useful to know, for example: 1) When is LDP/IGP synchronisation completed? Better not to have to guess. 2) When has GR restart completed. 3) Case of a label request with a typed wildcard. It'd be nice for the LDP speaker which issued the request to know when its peer has sent all the requested labels. Our approach is LDP notification with a new status code for end-of-LIB (for a FEC type). So send the end-of-LIB status code plus a typed wildcard FEC specifying the FEC type for which the advertisement is completed. Issues with backwards compatibility. Issue is that LDP spec (RFC3036) assumed that new status codes could be defined but doesn't say what to do if you get a notification msg with a status code you don't understand. The draft uses LDP capability so that when you initialise you say if you can process end-of-LIB. Peer will only send end-of-LIB if that capability has been advertised. Bod used the slides to give an example: Assume that R1 is active. R1 sends init with end-of-LIB capability TLV. R2 in this case can also support end-ofLIB so it sends a similar message. The LDP session is established and keepalives and label advertisements are exchanged. Once R2 finishes sending labels it sends end-of-LIB notification for IPv4. Once R1 finishes it does the same. There is another draft on LDP-IGP sync. That draft defines 2 mechanisms. One is similar to this one (but no typed wildcard or capabilities). The other enhances the label mapping message. The working group may want to look at that draft also. We would like comments from the working group on the current draft. ? - this is essentially harmless if I received it and didn't understand it. One of the things you may want to consider is a new FEC TLV that says "this label mapping message is the last one I'm going to send". That avoids sending label mapping followed by notification. So if there's a minor routing change then you just send one message. Bob - that's similar to the other draft. Ina - what if I expect the notification, but you don't send it? Shouldn't it be a MUST rather than a MAY. Bob - might be good to have relatively generous timeout. Can't always be sure peer will send it. Ina - (unintelligible) Alia - talking about negotiating a capability for this. Wouldn't it be nice to have a generalised capability saying how you'd respond to unrecognised status notifications so don't have a special case for every such one in future. Bob - will consider that. Alia - how do you envision a router determining when it's done sending the LIB? With LDP/IGP sync one issue is talkative sessions. It's not always easy to know. Bob - things can happen which may require label mapping a few seconds later or 10 minutes later. But after e.g. a session comes up the router will know when it has finished its initial set of advertisements. Alia - so more clarification on that is good. Yakov - the draft mentions that end-of-LIB is useful in various scenarios. That is true, but would be good to document how it is used in those scenarios. Luyann - very useful. When I was on the provider side we had LDP blackholing issues and issues with LDP/IGP sync. And issue of how we knew it was done. One question is what if some nodes can do this and not others. Have to set certain timers. Timers not by default. Non-PHB behavior and out-of-band mapping for RSVP-TE (Zafar) draft-ali-mpls-rsvp-te-no-php-oob-mapping-01.txt Slides:09-draft-ali-mpls-rsvp-te-no-php-oob-mapping-01.ppt --------------------------------------------------------------------- Issue of out-of-band mechanisms to bind RSVP-TE LSPs to application (e.g. with BGP, LDP). There is a need to identify local label at egress node to apply that mapping. Can't forward until have that out of band info. There are several cases where non-PHP behaviour is needed. The solution proposed in this is 2 new optional bits. One for out-of-band and one for non-PHP. The bits is not dependent on each other. Note that out-of-band requires non-PHP as have to be able to identify the LSP. The authors requested that this should be adopted as WG draft. Zafar - S2L Name ID for P2MP TE LSPs draft-ali-mpls-rsvp-te-s2l-name-01.txt Slides: 10-draft-ali-mpls-rsvp-te-s2l-name-01.ppt --------------------------------------------------------------------- The problem addressed by this draft is that P2MP LSPs in some cases need to know e.g. destinations. This draft lets you signal S2L names as well as LSP names. This makes it possible to debug destinations for a given P2MP tree within an LSP using the S2L name. this draft defines an optional object for the sub-LSP descriptor tuple from RFC4875. Can use the S2L_ATTRIBUTE to carry more stuff in future. Good comment from Adrian on using RFC4420 encoding. The author want more comments from the working group and that the draft is adopted as a working group document. Loa - not much support in the room. will take this to the list and get feedback.