IETF 68 Prague, Czech MPLS Working Group Working Group Upadate --------------------- Changes in IAB/IESG - Dave Ward is new rtg area AD, taking Bill Fenner's position. Status of Working Group Drafts ------------------------------ One new RFC (4781). Oldest doc from editors queue (been there 6 or 7 months). Three docs are in the RFD-ed queue. Six docs in IESG review. When an AD leaves he has to clean up before IETF week is out so Bill has been working hard to get these done: Finally agreed on ECMP draft and how to spell bits out. [Editor's note] the IP protocol number 1 is now reserved (as is 0). LDP spec is our first draft-standard. Ina drove this - so thanks due to her. A protocol write-up is needed on LSR self test. (George's action). ICMP draft. Companion draft in int area has gone through and been last called. So now done IETF last call on our draft. One comment but it was determined that the draft is correct and the comment wrong. So no major problems expected. Whole bunch of WG drafts: FRR MIB not yet updated post MIB doctor review. Tom will do this - expect it to be published soon. interas-lspping is relatively new. All need to take a look and comment. LDP typed wildcard. Authors want last call, will happen this afternoon and have until 2 weeks after IETF. Multicast encaps. Authors want comments - nothing else happened since last our last meeting. number-0-bw-lsps has no implementation so can't progress for now. But it may be that there is now a test implementation, and it might work. Ross seems favorable to progressing it... p2mp lsp ping - new version was published. Adrian - more updates. Supposed to meet with George to check is implementation ready, but forgot. Looking for people to review it and write code. p2mp ldp - new version will be published soon after IETF. Please review. p2mp ldp reqs - authors want wg last call. Will be issued after the IETF meeting. The is a group of drafts around MPLS multicast/upstream labels. Can WG please review these four drafts (and any others in same area) and make good comments by Chicago so we can progress... One non WG draft - andersson-rtg-gmpls-change. Focus changed over time. Has been approved by all relevant ADs, so will hit RFC editor queue soon. Been a pain for some time... George - contragulates Loa for pushing it through (with Adrian/Deborah). Incoming liasons - will speak about two of them (from ITU-T - arrived March 13th). 1) T-MPLS OAM mechanisms. want comment by end of March. Triggered response from MPLS and PWE3 WG chairs saying time was way too short. Sent mail to list today. will take around 6 weeks... 2) T-MPLS OAM reqs. Stewart Bryant asked PWE3 and TMPLS to review. Haven't had time to read comments from MFA. Been delayed as got dropped between chairs. Please comment on it. 3) Updated version of Y.1720 George + Stewart did a liason response. It will be sent for review. Original thing is OK as doesn't break MPLS (but MPLS may break it - not our problem). Once piece of ambiguous text that implies you might be able to put seq #s where the label ought to be in the stack. Very unclear and needs clarification... Draft-vasseur-mpls-3209-patherr-01 - JP --------------------------------------- This doc was produced because of soft preemption discussion (been going 3 years!) The issue is that misunderstanding on soft preemption. One suggestion from Adrian was that unless you undertstand hard preemption you can't understand soft preemption. so wrote doc explaining what to do with each sort of PathErr. Clarified for each error code whether it is intended to tear LSP down or not. Presented draft at last IETF. Discussed with other vendors - esp Ina (Juniper). could be big work to document. Proposal is to try to scope the error codes related to preemption. Might be sufficient to unblock the situation in the soft preemption draft. Need some other vendors to show up and say what they do - and then we can do regular updates. Helpful to document it... First Q is do we think it is reasonable to document what implementations should do? Not always clear from the RFC. And if we start with soft preemption then does that make it easier to progress the soft preemption RFC? Loa - my response has always been yes. But we haven't really delivered on our promises. Given that we see promise of doc and work in general the answer is yes. don't want another doc hanging for 2 or 3 years. JP - we can try to resolve preemption in the next month or two and then work on the doc with other vendors. Ina - agreed? JP - can the WG adopt it? Loa - fair number of hands. Nobody opposed. Will ask list. Ina - can we look at split that JP proposed, and do a new doc version which makes it clear what it addresses. Loa - if we make it WG doc it gives WG chairs revision control of doc and they can push on it. For me this is procedural and I'll be happy to discuss any split in the docs, but want WG to have revision control - so we can push them through... Ina - if our main goal is to unstick soft preemption draft then best approach is to address issues related to preemption first. If bundled together then there's a risk it'll sit around for years as Loa indicated. draft-leroux-mpls-p2mp-te-bypass-01.txt - Jean-Louis ---------------------------------------------------- There are limitations to using P2P bypass to protect P2MP LSP. noted that may actually have duplication during link failures as well as nodes (if the bypass for the failed link goes across another link that is already being used for forwarding). aim is to avoid duplication whilst retaining scalability advantages of label stack. inner label is backup LSP label (and is upstream assigned by PLR). outer label is P2MP bypass tunnel label. Use of P2MP bypass would compliment P2P. UA label is context specific where context is P2MP bypass tunnel. changes since last version: New co-authors Added support for link protection (see example above) LAN interface protection (P2MP tunnel to all downstream LSRs on the LAN) now 3 options to protect P2MP LSP (one bypass for all MPs, a set of bypasses reaching all MPs, or a bypass that reaches more than just the MPs) Clarification as to how to set bypasses up (local implementation issue) To be done: Simplify LAN interface protection. Since UA label needed for both primary and backup LSPs we can use the same context. Address case where MP doesn't support UA assignment (by using a mix of P2P and P2MP bypass tunnels) Want WG feedback on whether partial protection is ok if some MPs can't be reached (would have a new attribute in attribute flags TLV - RFC4420). Look at cases where PLR isn't directly upstream of failed resource. Conclusion - remains quite straightforward, and want WG feedback. In San Diego said would want WG status in Prague, so now requesting it. Loa - Q on protection. This can become extremely complicated. Cases where unless you swap to backup LSP for all traffic you don't save much per network. JL - in FT's network topologies this approach saves a lot of bandwidth. In some parts of network have P routers with 20 or so downstream LSRs. P2P bypass will give us 20x the TV traffic on some links. If you put the PLR two hops upstream of failure the b/w optimization may be different but impact recovery time. Always tension between recovery time and b/w saving. Loa - when you get into situation where b/w is scarce resource you have to make hard decisions. Adrian - FRR is not intended to put traffic onto a path that lasts forever. Idea is to recover trafic until you reoptimize. In case Loa showed you'd reoptimize the tree. George - in fact by nesting the tunnels you could change the EXP bits on the bypass so wouldn't interupt committed traffic. JP - you raise a good point. Might even be possible to signal the tradeoffs so each PLR could evaluate cost for bypass LSP and use two parms - how far from the point of failure and the cost of the LSP to decide whether to be PLR. George - don't forget we're talking about explicit routed tunnels. May be regrooming to different area of network. Backup tree may already be set up but because of geographic distance you may want to repair locally. Show of hands on WG doc. Good support... taking to list... LDP extension for Inter-Area LSP - Bruno ---------------------------------------- Draft allows FEC based on longest rather than exact match in RIB. Text added on RIB interactions. Issue is that with a single RIB change, the longest match is likely to affect multiple FECs. For prefix up check all FECs which are subset of *new* RIB entry to see if it is a better match than existing prefix being used. For prefix down check all FECs using the RIB entry. For next-hop change must change NHLFE of all FECs using the RIB entry. Conclusion is that this is straightforward, and solves an operational problem. It is stable and is being implemented. Want WG adoption. Ilya - idea is good and practical. but if you consider that may have one hop between ABR and destination then the area boundary has to pop label and resolve the next label using a RIB lookup and impose new label popped at next hop (doing another lookup). So inefficiency in handling... Bruno - LSP doesn't stop at ABR. IP route is summarized, but not IP route... George - good piece of technical work. but does it save a lot or move work from IS-IS or OSPF into LDP? have you analysed that? Is it worth the effort to put this in LDP? how many cycles are saved? Bruno - doesn't add work to LDP. All it does is remove prefixes from IGP. George - you still have to put disaggregated prefixes into every linecard. So when a routing change occurs you have to do X amount of processing. what is the new processing as a percentage of that? Bruno - hard to answer that from a protocol point of view. Advantage is that we can factorize some treatment. If we have 100 LSPs and path to ASBR changes then we have one event with 100 FEC changes, or 100 events with 1 FEC change. We save the IP work. Ina - for performance evaluation with/without this extension it'd be better to look at this from the operator's perspective. Do you really want to leak all those prefixes? What you pay in terms of performance on router is implementation issue. Loa - I guess we are at point where we need to send this to WG list and list our concerns, asking for comments before we make it a WG doc. Bruno - in San Diego conclusion was to get comments on list. Loa - hadn't heard Ina's comment before. Also George's. So you've requested WG feedback. George - poll of room on support is ok. but need to seriously think this through. ?? - this is about IGP scaling. ABR or L1-L2 router is the busiest router in the network. Anything that takes dynamics off the core is good. Some in favor, few opposed. chance to talk on mailing list. George - need serious discussion on list... Security framework for MPLS/GMPLS - Luyann ------------------------------------------ The question was raised in CCAMP as to whether this should be MPLS WG or CCAMP. For now is in MPLS. Final call must go through both of course... Issue is that various drafts have been stuck on Qs from security area. Can't just say "no new security issues". Maybe a better way to do this is to have a single document on security issues of MPLS and GMPLS in general to have consistency. Other each draft can ref this and adderence any specific issues. Scope - issues with MPLS protocols, specific operational issues for MPLS nets. May change scope in future. Outline of 00 draft: Need to define the trusted zone (e.g. your own AS). Will be emphasizing how to protect the SP core A new version will be issued before Chicago and we will be asking for WG status then so please review + comment. Richard Grossman (RFG security) - real good start. Approach of not inventing security mechanisms is entirely correct, but good to hint at what to do. Scope issues in current draft. What you say is correct, but you also mention syn floods, social engineering etc. But then insider threats may be important. Please look at RFC4230 (RSVP security properties). DoS is really important and scattered in doc - so maybe pull it out into one section. Important issues are (1) being able to filter at line speed. (2) not to amplify. Can't stop people sending DoS. Statement about encryption being expensive is left over from 1980s. Get used to it. Integrity checks are even cheaper, and sometimes that's all you need. Key management is important, neglected, and hard. Doc talks IPSEC. IKE is the tough bit. Suggest that the work of the isthmus and syslog groups be looked at. Reporting is important and syslog group is active and in late last call. Isthums may be more promising than SNMPv3. BGP is talked about, but OSPFv2, v3 and IS-IS are all important. IS-IS is different as not an IP protocol... Sam Hartman - agree this is important. I think that this is great starting point. If you want this to serve its function then it's going to be important to spend a lot more effort on the trust model. You have a trusted zone but don't talk about what people in/out of the zone are/aren't trusted to do. So hard to evaluate security. So most work needed there... Another area is going to be discussion of gaps. For example many of the protocols involved don't meet RFC4107. Need to call that out (but not fix it - as not your job). The one other concern is that not entirely sure that the goal of having something useful for security sections of protocol drafts is also consistent with giving operational advice. Think it's a good goal but set up a fairly challenging set of issues for one doc. Loa - Q for Sam (out of blue). Could we have a contact in the security area directorate? Sam - A group of us are meeting for lunch to discuss this stuff. Luyann - been thinking about trusted zones etc. Sam - to get past IESG you need more. Kireeti - I was curious that you had PCE in there but no TE IGPs. Much more widely deployed. Also don't think should be informational. Sam - doesn't need to be normative for security considerations. Adrian - tried to take notes as Richard was talking. Richard - good comments and can you please send to list. LDP Capabilities - Jean-Louis (on behalf of Bob Thomas) ----------------------------------------------- Motivation overview - abiity to negotiate enhancements to the base LDP specification at session init and then to enable/disable those enhancements later. Changes - tried to simplify encoding/processing. Removal of capability list TLV and ack mechanism for dynamically advertized capabilities simplifies things. Defined capability parameter - optional LDP TLV. Each capability has its own code point. No need for new registry - using existing LDP codepoint registry. "S bit" defines whether capability is being advertized or withdrawn. Also have ability to encode more complex capabilities. The upstream-assigned label draft has been aligned with this new capability. Loa - seem to be no Qs or comments. Authors want it to be WG doc. A poll of the room showed good support. draft-ali-mpls-rsvp-te-s2l-name-00 - Zafar ------------------------------------------ The requirements is for signalling of sub-LSPs in P2MP-TE. We don't want to overload the session naming for S2L naming. Becomes a meaningful concern where customers want visibility of S2L bindings in large networks. Thus we need two levels of naming - one for P2MP LSP name and one for S2L name. The solution is straightfoward. It also allows us to add future attributes at S2L level if we find them (for now only have S2L name). Loa - no Qs. Very few read the draft... very little support for WG status. nobody seems opposed. Take to list! George - need to get everyone to read it. draft-brockners-ldp-half-duplex-mp2mp-00 - Frank ------------------------------------------------- This one sounds complex, but is actually a simple extension of mLDP. There are a couple of scenarios (some inspired by regulators etc.) where you want to broadcast from multiple sources to a large number of receivers but don't want clients to be able to talk to each other. The application is similar to routed multipoint EVCs from MEF. This draft allows servers talk to clients (and each other) clients talk to servers (and not to other clients). Objectives: Simple provisioning - no reconfig when a new leaf joins (server or client). Automatic forwarding setup. Limited state. Avoid ingress replication. Today would use P2MP LSPs for server-client and MP2P LSPs for client-server, and have each client join to N x P2MP and N x MP2P (for N servers). Besides all the extra state, an operational problem is that need to reconfigure clients when you add a server. This draft modifies current MLDP behavior to allow just two trees (clients to servers and servers to clients+servers). It everages the P2MP FEC element to allow 4 FEC types which identify the upstream and downstream directions of the two kinds of LSPs. In principle it is very similar to MP2MP LSPs. The difference is we need additional behaviors to get to half-duplex behavior. Opaque value may be required e.g. for broadcast scenarios. Would appreciate feedback. Draft is a bit hard to digest, so adding an example to make it more readable... Kireeti - rather specific topology here (servers, clients with fixed roles, rules), so this seems to be a point solution. What you really want is to separate tree topology from LSP setup. Otherwise if someone e.g. has servers that don't need to talk to each other they need a new solution. So could end up with a huge number of drafts. I understand you want simple config. So let's separate the two problems. Have one mechanism for topology discovery, and one for creating trees, and glue the one on top of the other... Ina - seemed to me reading draft that assumption was that you have manual config. did you consider automating it. Also can you in a few words describe the scaling for forwarding/control plane as compared to building N trees? Frank - need to configure at each device if you're client or server. e.g. scenario with 50 BRAS in residential environment would have 25 x the state with separate trees. Venu - trying to understand benefits. Is the benefit that you just have one tree? Frank - benefit is 2 trees and no config at client when you add a server (e.g. when you add a BRAS). Venu - as compared to SSM trees? Frank - yes, not a tree per server in this case. Yakov - the reason why you need to configure each time you add a new server (today) is because you have no topology discovery. So need to look at auto-discovery as an option and then build trees to match that topology. Frank - I agree with concept of generalizing this. and we can probably do it. Yakov - as you yourself said it is a point solution, and we want to avoid those... draft-swallow-mpls-remote-lsp-ping - George ------------------------------------------- This mechanism is actually called proxy ping (except in the draft name which was kept because of the later draft deadline. No huge changes since last time. The mechanism can be used to do a leaf to root trace. A leaf knows to whom it sent the label request to join the multicast tree. The leaf uses a proxy ping to get that node to ping that segment. he can also send it the previous hop. It can then iterate up the tree to the root. It can also limit the number of ping messages that get processed by only going two hops at each step. On each iteration the leaf can scope the ping down to the particular next-hop that extends the LSP toward itself, since it has already discovered and verified that node. It can scope the node from which wants a response to the one two hops toward itself. So this compresses things and makes a really nice tool. Proxy echo reply is there to carry previous hop info and verify that a ping was (or will be) sent. There have been various changes since 00. The most notable one is that faking of the source address on the ping has been dropped. (It raises all kinds of security issues). A consistent source address is needed on P2P LSP to follow ECMP route, but since use cases are almost all multipoint (which has no ECMP issues) then this becomes much less useful. Loa - how many have read. Quite a few. Mostly in favor of WG status. nobody opposed. Take to list. draft-swallow-mpls-mcast-cv-01 - George --------------------------------------- This draft defines a keep-alive OAM mechanism for P2MP MPLS LSPs. It also can be used for MP2MP, but complete coverage only comes by running a session for each sender. There are a few differences when compared to unicast (MPLS-BFD). Leaves may be coming/going, that is the LSP may be changing dynamically over time. In BFD one can only take down the entire session to all leaves. We need to be able to take a leaf out of service (basically tell it not to alarm) without terminating the OAM to other leaves. The motivation came from customers wanting good OAM for P2MP-TE. High value apps sending TV or financial data so can't afford to lose it. Willing to create two entire trees, send data twice, and use OAM to do egress selection (equivalent of UPSR). Also applicable to M-LDP but in that case you are monitoring rather than doing repair. Allows reporting of failure indications. One requirement is to keep config to a minimum. Leaf configuration could be as simple as "Accept all mcast-cv sessions". All you have to do is send this msg from head and then everyone binds it. Of course in real world you may not want to accept every session. We're defining control protocol to control BFD session. Actual probing done using BFD. BFD draft not submitted last time I presented, but being worked on since last June. Dave Katz and Dave Ward doing it. It was presented in BFD the other night. New AD is also AD over in BFD and is also BFD chair and draft author. Poll of room in BFD indicated it would probably be accepted as WG doc once BFD rechartered to include it. BFD mcast has morphed slightly since last rev. 3 modes of notification to head have been slightly refined: 1) no notification (used in "UPSR" case - head doesn't need to know as it's up to the tail to repair and/or alarm). 2) unreliable notification (occasionally set poll bit and get replies back, but not 100% guaranteed that they'll arrive) 3) reliable nofification (use set of P2P BFD sessions and unicast to leaves you've not heard from). Dropped scoping after discussion with Adrian. Never heard the req. from providers and don't want to add processing. Adrian - we goofed. After our conversation you took it out and I put it back in (into MP LSP ping). We need to agree if we want scoping to a set of nodes or not. Adrian - we had scope to single node or all nodes before. Are WG happy to take that back out again... Loa - fairly new, few have read The draft. Most of those support WG doc. Nobody opposed. To list. draft-ali-mpls-rsvp-te-no-php-oob-mapping-00 - Zafar ---------------------------------------------------- George began with an introduction: Two issues have arisen in RSVP-TE. There have been discussions between Rahul, Yakov, Zafar and myself. We we're able to come to a consensus in time to meet the ID deadline, but have since. We wanted to take the oportunity at this meeting to introduce the problem so that we can move forward in future meetings. The issues are first, sometimes you need no-PHP in order to have the proper context at the terminating router. However there is no way to signal this in RSVP-TE. Second, the binding information for a tunnel's use may come asynchronously and this needs to be indicated. A side issue here is that the semantics of the PID signaled in the RSVP Path message may not be adequate. Zafar has put together a draft presenting the problem and our proposed solution. We didn't come to closure in time to publish the draft, but have reached closure since. Zafar - The draft was posted last night. Should be there in a few days. One issue is where you need to bind an RSVP-TE tunnel to some out of band mechanism. That is, the info as to what LSP to use comes out of band (e.g. via BGP). To do this we need local label info at egress to idenfify incoming tree. The two operations - signalling of RSVP-TE LSP and binding out of band are asynchronous - could be asynchronous. LSR receiving binding info out of band can't do forwarding until that binding shows up. To avoid cases where you didn't get binding for unreasonable amount of time we need cleanup to avoid tying up resources or blackholing. The egress MAY send PathErr if an out of band mapping is not received in a reasonable period of time. Another app could be multicast RPF check. Or determining that we're receiving traffic on the expected LSP. Also with UA labels where the context is in the MPLS LSP we need the non-PHP behavior. Solution is straightforward. One bit for non-PHP behavior and one to indicate that mapping will be out of band. The two new bits are completely independent. When an egress receives non-PHB bit it must assign a local label. The ingress may use the RRO label recording to check it and send a path tear if egress has assigned null label. Yakov - granularity of out of band mapping may be finer than what we can express with L3PID. George - so out of band mapping could overwrite L3PID. Yakov - exactly. George - while bits are independent I can't think of a case for out of band mapping being used without turning off PHP. Conclusion - Loa ---------------- A big thank-you to Bill Fenner for his 5 years of service as routing AD! Meeting closed - see you in Chicago!