` SPRING WG - Source Packet Routing in Networking Wednesday, July 24, 2019 10:00 - 12:00 Wednesday Morning Session 1 Room: Laurier Chairs: Bruno Decraene Rob Shakir =============================================================================== o Administrivia (Concerning criteria for slots in SPRING WG sessions.) [Acee Lindem] WG can request reviews from Routing Directorate at each of these stages. [Bob Hinden] 6man has a process to have 5 mins, 3 content slides and no discussion for -00 drafts. This could be a way forward. o SRv6 Network Programming (10:10) [Kamran Raza] Mostly update from IETF102. Next: align with SRH (6man-routing-header). Issues: ENH defintion (to be aligned with 6man-routing-header); NH 59 (discussion on the list, no consensus) [Bob Hinden] "No next header" has a clear meaning. Should not be reused. Request new allocation [Joel Halpern] The WG cannot adopt the document with the use of ENH 59. There are exisitng uses which this is in violation of. Must use an alternate value. [(Unknown)] Cannot insert extension headers into packet without encapsulation. [Lorenzo Colitti] We should think about the amount of address space that we need for this solution. Draft says that there is a /32 per router which seems very expensive. Examples use lots. We should give examples that guide operators to use a reasonable amount of address space. Draft should also consider what a /reasonable/ amount of address space - and evaluate whether this is doable. If we decide that we need to have a /8 then it would use significant amount of the Internet's IPv6. [Darren Dukes] This is just an example used for brevity. [Lorenzo Colitti] If the examples are a /32, then we should expect that people use /32s -- the examples should be more reasonable. [Jen Linkova] +1 to Lorenzo statement. Draft may be confusing v4 and v6 because of /32 usage :) No justification for /32 and people follow examples from the draft. Need more details on requirements [Andrew Alston] Since this isn't scoped per router, then other elements (e.g., containers) might need this space too. This makes the usage even worse. +1 on looking at the real address space requirements. [Stewart Bryant] About 100 types in the regsitry. Think about introducing SHIM. [Ron Bonica] ENH referred to as a "upper layer header" - suggest to use the same terminology. When ENH does not follow SRH, then need to look down the packet, including sometimes need to decrypt. Could put this in the destination options. [Darren Dukes] Pseudocode in SRH draft walks through the procedure for looking at headers. This draft needs to adopt this. [Ron Bonica] Need to look way beyond routing header. Complexity goes away if you use option in destination header [Bruno Decraene] Suggestion to use new header - will be followed up. o Using DHCP to Manage Node and Ring SID Assignment (10:29) [Kireeti Kompella] Just a proposal.Some types of SIDs need to be unique. SIDs should be consistently assigned to routers at the start (not a MUST but preference). Any router will make a unicast request a SID type it wants. Once assigned by DHCP server, it can be advertised via IGP. Timers for lease and for how long to preserve (sticky) the allocation to a node. Useful no Node, Anycast, Ring, SRv6+, etc SIDs. [? via Jabber] How does this work when we need two SIDs per device? [Kireeti Kompella] If you want 2 SIDs for the same prefix, probably need to use extension [Robert Raszuk] Why not use LISP rather than DHCP? [Kireeti Kompella] DHCP is good tool for making allocations. Well suited for this. Can use SRMS too. [Jeff T] Looks like option 82. You don't need to create configuraiton on the server. Just make it ephemeral [Kireeti Kompella] Problem is making sure SIDs don't clash. SRGB management is not an issue. [Stephane Litkowski] Flex Algo, ??? [Kireeti Kompella] This is similar to the request for multiple SIDs -- we would perhaps extend the DHCP request to be able to make requests for specific algorithms. [Stephane L] Regarding manual allocation, we have a resource allocation that is automated. [Kireeti Kompella] Important to make a recommendation, not a requirement. [Robin] Had already proposed a solution based on PCEP and BGP to do SID allocation as well as other parameters. When proposed this in BGP/PCEP then there were some challenges around whether values were dynamic. If this is also applicable to SRv6, then the IPv6 addresses could also be allocated by DHCP. [Kireeti Kompella] Agreed, but people think that IPv6 loopback address needs to be known in advance, not dynamically allocated. [Tom Herbert] DHCP is clever about backup servers and use boradcast for things. Rely on this. [Kireeti Kompella] ACK o IPv6 Support for Segment Routing: SRv6+ (10:44) [Ron Bonica] SRV6+ - make a distinction between topology instruction and service instruction. Topological: service ingress node. Service: service egress node. Reasons for decoupling: use most appropriate extenstion headers (RH affects routing, DOH affects processing beyond routing). Header of one type not polluted by information from other types. There is a complete implementation on Linux and Juniper JUNOS PoC is coming. Next: SPRING WG adoption, 6MAN adoption [Robin] Is there any control plane work for this? [Ron B] Yes, there is associated control plane work. There are proposals in LSR and IDR for the extensions that are required. OSPF is missing. [Robin] The information that is carried by SRH and CRH is the same information. Do we need a new set of specifications to cover this? [Ron B] Is the incremental improvement of SRv6+ vs. SRv6 something that's worth it. Will leave this to the WG to discuss. [Robin] If you compress the header, you need to introduce state in the forwarding plane. [Ron B] There is additional state per SID, not per path. Look at the IS-IS draft. [Robin] [Ron B] Are you saying that you support 10 SIDs today? [Jim Guichard] Mentioned no TLVs required. Plenty of use cases for carrying metadata in the packet, today in the SRH. If metadata is before the routing header, then there might be significant preamble before forwarding [Ron B] Not trying to compete with NSH. If metadata is big enough, use NSH. [Jim] If you hsve significant metadata then this will be an issue. Some other options, uSID and another proposal has been submitted. We need to compare the two approaches. [Tony Przygienda] 5G bandwidth is not free. Number of headers will affect economic (bandwidth). There is benefit to having separate transport and service layers, which this introduces. This has been the way that we scale networks typically. Supportive of this approach. [Gaurav] Don't see any reason for having another header. [Ron B] Technical arguments against this -- rather than there is another solution already. Encouraging improvement over things we have today. [Tom Herbert] Is it a replacement for SR MPLS? Is it complementary? [Ron B] It is complementary. SRV6+ mimics SR-MPLS where SRv6 diverges. [Tom Herbert] Does "+" mean that this is a superset? [Bob Hinden] As 6man co-chair, would like to understand whether SPRING is interested in this work. A clear message would be useful to ensure that 6man spends time usefully. [Wim Hendrickx] With SRv6 implementations with full flexibility will have penalties for implementations. Question - for the WG - likely we need an optimisation on top of SRH which is more performant (does not have the penalty). Question to the WG is whether we should adopt multiple of them. Draft in MPLS with MPLSoUDP which does the same thing as is being proposed here. We'll end up implementing all of them, which causes confusion/additional cost in the market. [Ron B] There are 3 ways to go: have a shoot-out between options, we can try merge options or allow all to grow and let market decide. [Wim] Believes that there is an optimisation needed -- would prefer to come up with a single way to go. [Andrew Alston] Overhead of SRH is not negligible based on the the analysis. Cannot justify deployment of SRGH because of the cost. Inflating IGP is another concern. [Robin] There may be other ways to solve this - e.g., BSID. We must understand the requirement -- there are other ways that this might be solved. [Mach Chen] It is different from existing SRv6 so use different name, rather than calling this SRv6. [Ron B] We can rename it to whatever you'd like. [David Melman] Identify with the issue of large SID lists. Isn't SR-MPLS over IP already a solution for this? [Ron B] That's an argument for removing both SRv6 and SRv6+. :) Some operators need SRv6. [David] SR-MPLS over SRv6 is over IP. [Bruno] SRv6 SRH already exists and been worked on 5 years. Need to understand the problem before proposing the solution and commiting to work. [Ron B] Move the conversation to the list. [Alvaro R] Want to understand the approach here, should we hold the work that is already in 6man whilst we understand what the constraints are? [Rob S] What is the problem trying to be solved, what are the constraints? We can then figure out what it is we want to progress through the working group. We'd like to avoid SRv6+, SRv6++, SRv6+++ whilst continually confusing the industry. [Alvaro R] With that in mind, then should we talk with Suresh and say to hold SRv6 until such time that we've decided what to do about these new proposals? [Rob S] It's not clear that this is what Ron was asking for. Read this as wanting an optimisation on SRv6, rather than a wholly new solution. [Ron B] Careful to be neutral about SRv6, asking for an assurance that we are not ossified with respect to SRv6, and we can continue to discuss the changes that we might make for this. [Suresh] Needs clarification how SRv6+ affects 6man. Current plan of record is that SRv6 will proceed to IESG. Going forward, 6man will also work on additional SRv6 extensions which have been gated by SRH. If there is a change to this required then 6man/INT area would like to understand this ASAP. o Network Programming Extension: SRv6 uSID Instruction (11:20) [Bruno D] Many of the comments on CRH apply to this draft too. We need to define a problem. [Daniel V] There are deployments that will support it. [Bruno] We knew SRH length when we defined SRH. What has changed here? [Darren Dukes] It doesn't change how SRH works. This is just another SID - normal operation for SRv6 [Bruno D] It changes the forwarding. [Darren Dukes] We re-use the SRH (ref pseudocode). This is just another SID which has its own behaviours. [Bruno D] It doesn't mean we don't change anything from v6 standpoint. Need to ensure alignment with 6man. [Cheng Li] It is a right direction to enhance SRv6, but the solution is not flexible enough. It only supports loose TE. Prefix has changed from 16b to 32b that affects existing allocations, all the addresses are burned in that block. Too expensive. Implementation should be done for normal SID and uSID when a new SID is defined. Also, per SID routes advertisement is a problem. Why not use huawei's proposal? One update for all SIDs, forever, no need to update for new SIDs.No routes are needed as well. [Daniel] Take this offline, multiple points. [Andrew Alston] Responding to "just another SID type". It's not. If it's just another SID, then would not need to be distributed to every node in a way that this needs to be installed in the IPv6 FIB. IGP impact may have significant consequences. Nice that this works on legacy hardware, but legacy devices are small FIB devices -- so whilst we tradeoff support here, we also load those edge devices. Must think of this as an address not just a new SID. [Daniel V] IGP scale can be addressed via some techniques. Other comments to be addressed on the list/offline [Andrew A] I In order to reduce FIB then we use L1/L2 etc. Can you explain how L1/L2 stitching whilst preserving the ability to steer across both, without flooding L2? [Daniel V] Take it offline [Kamran Raza] Techniques where can advertise one prefix. Will continue to advertise IPv6 prefixes. [Stephane L] Question to WG Chairs: Regarding information needed to define a problem. Important aspect is extra cost for ASIC production. Do you expect vendors to answer this? Take a survey with the vendors? [Rob S] We know it's not gonna be perfect but there are some known constraints. [Jeff T] There is a means to be able to advertise SID depth capabilities into the IGP through MSD. This information exposes the capabilities. [Bruno D] There is a draft for IPv6 too that covers this -- at which point this will be public. [Ron B] You retain the trace where the packet has been. Is this possible in uSID? [Daniel V] Yes. Draft covers this. [Kamran R] SRv6 has it. [Ron B] Why is it in the routing header given it doesn't affect routing? [Daniel V] Move it to the list. [Gaurav] This is a step in the right direction. Handles the MTU restriction. [Jen L] How much address space is needed here? Not clear in the draft. Where does the address space come from? Worried about use of public address space without sufficient justification. [Daniel V] It does apply to many types of prefixes. Will be clarified in next version. [Shraddha] Is this also a uSID? [Kamran R] This will be covered by feature work in the draft [Robin] Can we use a binding SID solution? [Peter Psenak] There is no difference between dvertigin uSID and normal/regular SID. Would like to learn about the concerns. [Ron Bonica] If we can put SIDs into the SRH, then what do we need uSIDs for? [Darren D] Draft already covers whether SRH is added or not. No discussion to be had here? [Ron B] (addressed to Alvaro) If there are new interactions between uSID and other SIDs -- how far is the network programming draft from being mature? [Bruno D] Current uSID draft is a -01 presentation, currently there is no interaction with the working group drafts. [Daniel V] If you can contribute to the uSID then we can work these items out. o TTL Procedures for SR-TE Paths in Label Switched SR-TE Paths. (11:42) [Zafar Ali] Do we need to document the way that this should work? [Shraddha H] It is not clear from the existing documents. PHP behavior needs to change so clarification is required. [Zafar Ali] Did you receive comments that this needed clarification? [Shraddha H] Comments from operators and also from the last presentation @IETF. [Lou Berger] Might be a comment for MPLS WG. Would be useful to clarify on what SR-TE is. We need a definition of SR-TE. Chairs should also clarify what SR-TE is. [Shraddha H] ACK. o Operations, Administration and Maintenance (OAM) in Segment Routing Networks with IPv6 Data Plane (SRv6) (11:50) [Zafar A] Summary: Implementations exist. Verfied interop. NEXT: Ask for SPRING WG adoption. [Bruno] We were waiting for SRH to be completed. But we don't really care where this is done. Since this changes SRH then 6man has the priority. Chairs will discuss with the 6man chairs to determine whether this is something that they will adopt. o Segment Routing with MPLS Data Plane Encapsulation for In-Situ OAM Data (11:57) [Rakesh Gandhi] NEXT: Updates regarding hashing and hop-by-hop IOAM. Ask for SPRING WG adoption. [Bruno D] Was it presented to MPLS WG? [Rakesh G] Yes. [Bruno D] [Jeff T] IPR concerns. Will request review from Ericsson [?] Why do we need this work? The following drafts were not presented due to running out of time in the WG session. o SRH Encapsulation for iOAM o PMS/Head-End Based MPLS Ping and Traceroute in Inter-AS SR Networks o BGP-LS Extensions for Inter-AS TE using EPE-Based Mechanisms o YANG Data Model for IS-IS SRv6