Source Packet Routing in Networking (SPRING) WG Tuesday, November 3, 2015 09:00-10:30 Tuesday Morning session I Room 303 o Administrivia Chairs 10 minutes - actual start 09:00 John Scudder: Note: note well, some docs in last call, problem statement to IESG, moving fast to save time for presos. o Update on WG drafts 10 minutes - actual start 09:02 Roberta Maglione Roberta Maglione: presenting on behalf of Stefano who couldn't make it - updates to various drafts: segment-routing-problem-statement - version 5, fixed IP addressing. segment routing - version 6, added clarifications on anycast, domain definition, fixed ip addresses, still some comments coming in next rev. segment-routing-mpls - version 2 only fix typo's segment-routing-ldp-interop - just accepted as WG doc, some comments from Sasha need to be integrated still (add some use cases, update refs, see list archive) segment-routing-msdc - just accepted as WG doc, fixed author list segment-routing-central-epe - just accepted as WG doc, fixed authors list, fixed ip addressing filfils-spring-sr-recursive-info - just published -01 with new co-author, allow prefix to be resolved to SID allocated to different node, couple of use cases - node could have multiple loopback address and forward traffic to different nodes based on which service (one service per loopback) or to different interfaces locally attached per service. requires new TLV to specify different SID's. francois-spring-segment-routing-ti-lfa - moved to RTGWG, renamed (still individual draft) Q&A started at 09:10 Robin Li/Huawei: Interoperability between LDP and SR - not sure my concerns have been addressed with this draft - may be issues with LDP DU (downstream unsolicited mode) that have not been taken into account. Need to bound the scenarios as there are many of them, and focus on interoperability of the most important ones. Roberta: 4 known implementations so be specific about what problems you have seen on the list. Robin: can you confirm they cover all these use cases? Roberta: we need to understand your concerns better. Chris Bowers/Juniper: would be useful to have implementation report that lists what features are in various implementations. That would be used as a basis for checking how particular aspects are addressed. John Scudder: we will create a space in the SPRING wiki to host implementation reports (as done in IDR). Jeff Tantsura: orange published MPLS conference paper last year, there are some (other?) industry presentations on interoperability as well. Roberta: I was referring to what was presented in MPLS world congress forum. Robin: 2nd comment - in RTG area meeting AD expressed concern (actually Alvaro) about use case drafts in routing area meeting (scribe note: no clear direction was given in the area open meeting on the resolution on whether use case docs should be published - would be dealt case by case per Alia) John Scudder: we encourage people not to just publish use case documents. If there are interesting and new use cases that cannot be addressed via current use cases documents then time can be spent on publishing corresponding use cases documents. We can take this to the mailing list and continue the discussion there. o Anycast Segments in MPLS based SPRING 20 minutes start 09:16 Meetecho 0:16:00 http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_SPRING&chapter=chapter_1&t=960 http://tools.ietf.org/html?draft=draft-psarkar-spring-mpls-anycast-segments-01 Pushpasis Sarkar Common Anycast SRGB (CA-SRGB) - new term we have defined - defines majority network devices use a single SRGB - you can define this to help interoperability across implementations as a vendor. The scope since last revision has been reduced to anycast prefix originators that don't have same SRGB as CA-SRGB. The diagram depicts two nodes that have 8000-9000, two with different ranges, so 8000-9000 operator would configure as CA-SRGB. other nodes would implement virtual lookup table to map the label derived from applying the index to the CA-SRGB and create mapping to local (real) SRGB on these nodes - depicted on bottom of slide. typo on right side mapping table on diagram in slide 7 - incoming 8080 should have mapped to outgoing label 6080(R2), not 8080. anycast devices from those not sharing CA-SRGB need to lookup 2 labels (anycast Label --> Virtual LFIB; Second label lookuped in the V-LFIB) Q&A started at 09:25 Meetecho 0:26:00 Robin Li/Huawei: This use case seems to be useful. How do you plan to provision the anycast segments? By means of some automation? Pushpasis: You put the same IP anycast address and SID on all the nodes involved. Shahram Davari: are you proposing any changes to MPLS dataplane? Pushpasis: this draft requires recursive label lookup Shahram: that's a change Pushpasis: lot's of implementations do this already, like for L3VPN Shahram: big change Pushpasis: I don't think so, but there may be some hardware that may not support (no agreement) Shahram: recursive label lookup anybody can do, it's the recursive look up on a different database which is difficult Martin Horneffer: This proposal lets devices which can configure a CA-SRGB stay with it. Only devices not supporting the CA-SRGB would need to implement the virtual LFIB in order to still support anycast segments. This really is the best solution possible Shahram: I advise not to go that route and just mandate everything use same SRGB John: we can't reopen the discussion on whether this is a global label - resolved discussion in beginning of SR o Addressing SID conflicts 15 minutes - 09:30 Meetecho 0:31:00 http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_SPRING&chapter=chapter_1&t=1830 http://tools.ietf.org/html?draft=draft-ginsberg-spring-conflict-resolution-00 Les Ginsberg It's important to reach consensus on usage conflicts that may occur due to mis-configuration - so far no consensus reached, so we unblocked IGP drafts w/o resolution to move forward and we want to try to resolve in Protocol Independent group (Spring). first rev may not be agreeable, published to get input. draft tries to be agnostic on approach - but may have not done this well and we may have choose wrong approach based on comments - we presumed most common case of issue is mis-configuring a new range alternate proposal - reject entire config - validation is already done by implementation before allocating labels - so this should be ok in practice as a pre-check by implementation 2nd issue draft discusses - not going to cover today (slide 4 detail) - example on slide 5 we cover two types of conflicts - prefix conflict (different SID's for same prefix) and sid conflict (same SID for multiple prefixes) - if you don't like the names, please send feedback. in prefix conflict if scoped to VRF, will only be scoped to VRF. in SID conflict is across VRF's so is wider scope. two approaches to resolve conflicts (slide 6) 1st approach - either ignore all things in conflict (good as causes visible issue - all things impacted, operator becomes aware quickly) - downside to that approach is larger traffic impact. 2nd approach - use preference rule of some sort to choose one over the other, some traffic may still be delivered, but may be harder to diagnose. draft just presents - does not pick approach yet, but does give some ideas (slide 7) on what types of restrictions there are on preference based rules: don't use source (as ABR may be scoping visibility), same for route type. last issue - prefix advertisements via SRMS - should configure both when making choice. more thoughts on preference on slide 8 - no way to know for sure which is correct, no guarantee all traffic can be delivered. Priorities for choosing approach: detect, report, consistent behavior, don't over engineer a solution to conflicts, very minor emphasis should be placed on resolution behavior than the 4 top priorities. looking for feedback and to resolve longstanding issue - asking for adoption as we really want WG to work this issue since IGP groups could not reach consensus. Q&A started at 09:43 Meetecho 0:42:50 Acee Lindem/Cisco: as OSPF WG chair, support this. Detecting is the hard part, resolving afterwards is simpler. John: is that with your OSPF WG hat on? Acee: yes. Although we could WGLC the OSPF draft without waiting for this, it would be better to have it resolved before. Pushpasis: conflict resolution - I think ignore option is better. Next comment - relaxing the check for SID conflict when N flag set to 1. If we just relax we should be fine and still be detecting misconfigurations even without implementing something complex. Les: I think this is a different issue. Pushpasis: I am talking about mapping multiple loopback addresses to a single SID - like on slide 5 this would create an issue for this application. Les: this draft talks about the conflicts within the legitimate advertisements, I don't think this issue is not worth discussing, but not in context for this draft. Pushpasis: Won't be an issue if you would treat this case as a non-conflict. John Scudder: I think Les is saying he does not want to define what a conflict is. That is not a normative formalism. Les: I think no. The advertisements are syntactically erroneous. Pushpasis: my point is I'm trying to exclude this scenario from being defined as a conflict. Les: we have other drafts that look into that, but I still think we need to talk about that here too, wouldn't want to put in this draft. Wim Hendrickx: most of these issues are showing up when you configure something. This can be avoided by enforcing local checks. Trying to avoid these issues may be simpler. Try to minimize the impact instead of adding in the complexity of trying to determine what to use. We all try to minimize the impact in case of conflict, so as such we (ALU) prefer to select one of the entry in conflict rather than to ignore all of them. Important to have this draft to have deterministic behaviours across different vendors. Les: I would agree, prevent problems from ever occurring is optimal. Jeff Tansura: support adoption, service providers may have different approach (prefer or ignore). This is an operational problem. Bruno Decraene/Orange: Speaking as an independent contributor and a network operator, this is important work but the draft should evaluate more the consequences of these conflicts on the network traffic. On slide 9, I think should have another priority to evaluate the consequences on the customer traffic after first three. I am concerned with the mapping server advertisements - single message containing multiple advertisements. Single error there may affect multiple mappings and thus affect large number of customer prefixes. Bruno: Second point - what you have written is right on slide 8, but that is one part of the picture. On bullet 1, I do not know the intent of the network operator that advertised me the prefix, but do we need to know the intent to make a choice? On bullet 2, no matter which prefix is chosen out of multiple, we cannot guarantee that the traffic will be operational. But that's not a reason to try to reduce the consequences. (in general supports resolution preference versus drop to lower impact to customers - thinks draft is not balanced on this in his reading) My reading of the draft is that one opinion is being pushed. There may be other ones too. Les: i think we agree on a lot more than we disagree, so let's continue discussion. Bruno: it is important to address these points, i think we should fix before adoption. Les: could you address on the list specifically those two points on the list if they are blocking adoption? Bruno: I'm not saying it's blocking, just should be discussed. John Scudder: what I hear initial approach was - here is a bunch of solutions, and we will place one on the table. Seems that we need to add other approaches too. If you have comments, please send text. Shane Amante: network operator - draft needs to move forward, but could what be considered a misconfiguration actually in some networks be a merger/transition activity configured deliberately? Les: there was a discussion in WG about problems associated with mergers, SID conflicts, different protocols used, etc. We agreed that we need to support that and protocol specific contexts and redistribution need to be addressed for transition scenarios. But that is not the subject of this draft. Shane: I understand if you are talking about different IGP's in the networks, but if same IGP in both networks and there is conflicts, I don't know if this draft is right place or another but should be addressed. Les: merging two networks it does not mean that IS-IS is on one and OSPF in another. It is about instances of the same in different domains. Shane: OK, but let's see what WG thinks. John: flashback to IDR related issues - short summary - spent many years trying to keep simple by just cycling session if we couldn't understand, then operators beat us into changing (RFC7606: Revised Error Handling). I would like to encourage the WG to consider that experience before arbitrary deciding to do the thing that's easiest for the programmers. Les: You survived those last 20 years somehow. :-) o Advertising Per-Algorithm Label Blocks 15 minutes - 10:01 Meetecho 01:01:20 http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_SPRING&chapter=chapter_1&t=3680 http://tools.ietf.org/html?draft=draft-bowers-spring-adv-per-algorithm-label-blocks-02 Chris Bowers Chris presenting, made changes since Praque - added Uma (co-author) and added multi-topology not just multiple algos. slide 1 - bit of review - this is normal computation any implementation has to do to figure out label for SPF routing to destination (add label block for neighbor + index advertised by dest to get label for sending to that neighbor). slide 2 - two ways to implement option 1 - one big label block, assign different node index for every dest / algo / topology combination option 2 - one node index, different label block for topo/algo pairing slide 3 - meant to be provocative to show the clean ordering of option 2 versus option 1 (view in color or eyesore looking at numbers). only showing 6 nodes for simplicity but could be thousand nodes (imagining operator leaving some space for an additional few nodes and topo/algo pair for network growth/change). option 1 deliberately shown very poor but illustrates any organization has to be imposed externally (by operator through CLI - possibly proposed by Les on list). so next slide shows option 1 can be similar to option 2 once configured like it with operator per node configured offsets (per algo/topo). case for option 2 vs option 1 - SR doesn't need targeted LDP (to exchange labels between remote nodes) good but needs assignment of node index which is bad. generalizing SR to other topos/algos makes it more bad since there is even more configuration complexity. option 2 makes it less conf complexity as less for operator to configure since don't need to do algo/topo offsets. when I first saw SR algo support - i thought elegant use case for MRT label distribution - but less attractive if you have to configure offset. next slide shows sub-TLV req'd to support exchanging this information (in IS-IS). non-zero values only - zero values (default algo/topo only in current SR TLV) Q&A started at 10:16 Meetecho 01:16:20 Ahmed Bashandy/Cisco: In slide 'Label computation', option 2, I would suggest having something like "offset,t". Regarding the configuration, you still need to maintain SRGB per algo/topo configs instead of offsets there, isn't it about the same? Chris: per algorithm per topology label blocks are locally significant, whereas offsets need to be non-conflicting. Option 2 does not require that label blocks are unique per router. Ahmed: but it can be fragmented too. Chris: Yes. I have it as example as single continuous block, but it can be fragmented. Ahmed: In option 1 it needs to be the same block and offset per topology, that is the only complexity that I can see. Chris: if you look in the draft there are more complicated scenarios I didn't discuss. so far we have assumed that we can allocate a single large block on each implementation to cover the network needs (may not be true). Ahmed: Let's go by example of option 2. I can allocate 10 SRGBs for 10 topologies, but use offset. Chris: That seems to be even more complicated. You are saying you would advertise multiple ranges? Ahmed: This seems to be a local verification mechanisms on the CLI level, do I really need to add functionality to the protocol? Modifying the protocol to advertise that informations seems to add complexity? Chris: there is no way to stop operator making mistake by configuring wrong offsets on different boxes in network. Ahmed: do we need to modify all protocols to prevent operator mistake? Chris: I think if we had put this in originally no one would be arguing about it, but we are now at a stage to think about supporting multi-algo/topos long term. Les Ginsberg: I have a more fundamental issue. It seems what you are proposing here invalidates the current way of advertising SIDs. Your proposal is that you have the same prefix and SID per protocol per topology, and that is not backwards compatible with the current way of advertising prefixes and SIDs. Chris: I am happy to add text that clarifies how this works, but in deployments everything currently has a=0, t=0. John: we are mostly out of time. Les: Prefix reachability advertisement includes one topology and one algorithm id. Chris: set to zero - I will propose some more text on backward compatibility. John: please resolve this offline. John: take to list or hallway time Ahmed: it seems like folks keep posing issues with draft and you fix the nit, but seems overkill for just operator mis-config o Interconnecting Millions Of Endpoints With Segment Routing http://tools.ietf.org/html?draft=draft-filsfils-spring-large-scale-interconnect Dennis Cai 10-15 minutes Not covered due to time, may be scheduled as a virtual interim meeting per John S. o Tunnel Segment in Segment Routing http://tools.ietf.org/html?draft=draft-li-spring-tunnel-segment-00 Robin Li 10 minutes Not covered due to time, may be scheduled as a virtual interim meeting per John S. Meeting concluded 10:27.