SPRING WG Source Packet Routing in Networking 9:00 - 11:00 Wednesday Morning session I Room: Chitlada 2 Chairs: Bruno Decraene Rob Shakir =============================================================================== o Administrivia Chairs - Note well - Scribe - Blue Sheets - Document Status 10 mins 9:00 [Zafar Ali] The charter does not specify that we cannot progress SRv6 docs. There will be a backlog if we block on this. [Bruno Decraene] Protocol extenstions must be worked on in routing protocol groups [Zafar] SPRING should not make this blocking work. [Bruno Decraene] Progression expected in 1-2 months [Martin] This doesn't mean that you can't work on your doc. This is just for adoption. [Bruno] We can assume that this will be adopted -- so there will be meeting slots, and support for advancing - but it won't be advanced until such time as we have SRH progressed in 6man. [Zafar] There will be private discussion on this work -- this will cause stability issues for adopters and implementers. [Rob] Private discussion is only driven by authors - please discuss on the list. [Martin] We do not drive the pace of SRv6 work in 6man. ---------------------- o UDP Path for In-Band Performance Measurement for Segment Routed Networks - draft-gandhi-spring-udp-pm-02 - Rakesh Gandhi 8 mins 9:10 [9:18] Draft was also presented at IPPM. Authors requested working group adoption. [Greg Mirsky] Using well known UDP ports creates a new vector in an attack and draft doesn't include security considerations. Working group document (STAMP) in IPPM regarding properties in the draft so why to reinvent the wheel. [Rakesh Gandhi] [Greg] Why not use TWAMP-light? There's existing implementations. 6374 works fine for SR-MPLS but not SRv6. [Rakesh] SR has both SR MPLS and v6 so you're not gonna ramp TWAMP on some nodes. 6374 has been around but STAMP (?) is new and not deployed yet [Greg] STAMP is backward compatible [Stewart Bryant] 7876 in early version had defined ports and there was a pushback - policy is to avoid well known port allocation. Use dynamic ports [Rakesh] We would otherwise need to add negotiation per-LSP ping. [Stewart] You should have an initial discussion with the port allocation folks to understand whether this is a possibility, otherwise there'll be re-engineering required as happened with 7876. [Sam Aldrin] Are you making sure Anycast is covered? [Rakesh] Needs discussion [Sam] What are you doing at the egress node? How is it punted at the egress? [Rakesh] UDP header is exposed. It is in the payload not in the stack. Label header only till the egress [Greg] Return path TLV already in BFD draft. Consider reusing. [Rakesh] We can make the specification similar -- IANA allocation will still be required. [Greg] In SRv6 if you don't have integrity protection/security then this will be a challenge. [Rakesh] We can add that. [Bruno] follow up in the list ---------------------- o Performance Measurement in Segment Routing Networks with MPLS Data Plane - draft-gandhi-spring-sr-mpls-pm-03 - Rakesh Gandhi 7 mins 9:18 [9:30] [Stewart Bryant] Colored packet marking? This worked in MPLS-TP since there was no ECMP - and needs some extension in MPLS for this. [Rakesh] Yes, this relies on the coloured marking. It does rely on the extensions in MPLS. [Stewart] Do we need twice as many Node-SIDs? (e.g. synonymous flow) [Rakesh] It only needs to be unique on the egress (local SID works) [Stewart] It needs to be unique for each possible source. [Greg Mirsky] Other methods than inband probes? [Rakesh] Can be done out of band. [Greg] This method is stated to be in-band, but is there actually an alternative to having in-band for effective OAM? [Rakesh] End to end delay measurement the same as the actual traffic. [Greg] This doesn't need a draft as it is required [Robin] Should it be carried in SPRING on MPLS WG? [Rob Shakir] Needs discussion ---------------------- o Resilient MPLS Rings - draft-kompella-spring-rmr-00 10 mins 9:25 [9:40] - Kireeti Kompella No comments ---------------------- o Segment Routing for Enhanced VPN Service - draft-dong-spring-sr-for-enhanced-vpn-02 - Jie Dong 10 mins 9:35 . [9:47] [Bruno] There is a related document in TEAS (draft-dong-teas-enhanced-vpn). [Stephane Litkowski] How do you partition resources by allocating new SIDs? [Jie Dong] Multiple technologies in the forwarding plane [Stephane] So it is separate logical link (for example VLAN) [Jie] Can be logical link or can be hidden from routing protocol [Stephane] similar than LAG members [Jie] yes, similar to that [Ketan] There is a virtual network defined here. How are these networks constructed and resources grouped? [Jie] Clarification -- you mean, how do you know that SIDs are grouped to form a network? [Ketan] Flex Algo has different algorithms for prefixes. How do you achieve that? [Jie] One approach is to use multi-topology to associate link+node SIDs (using MT-ID). [Ketan] Would be useful to clarify if this is related only to MT. Scalability analysis of how many partitions would be useful. [Lou Berger] What the underlying resource that an instruction maps to is dependent upon modelling. It can be queues in the hardware, or separate links etc. There will be scaling considerations required. MT-ID is only one option for different topologies - controller can know this without IGP extensions. TEAS draft should not discuss these trade-offs, but rather SPRING draft should link the use cases, such that then TEAS is able to map to the implementation. [Stephane] If you want to partition using queues you can use DSCP bits today [Lou] This has scaling limitations since the namespace is limited. [Bruno] Could you consider what the partitioning approach is, and analyse the scalability of your approach. [Jie] We can cover this following the meeting and post to the list. [Jeff Tantsura] You need to figure out how to interact between the number of services and number of loopbacks (one next-hop per service). ---------------------- o Path Segment in MPLS-Based Segment Routing Network - draft-cheng-spring-mpls-path-segment-03 - Mach Chen 10 mins 9:45 [10:03] Authors requested working group adoption. [Greg Mirsky] I see that you have parallel work on SRv6. You could consider having a single document covering path segment for both SR-MPLS and SRv6, since the issues are likely to be the same. Not sure that removing 2 ID labels brings advantages. Some segments may require more SIDs.. [Mach Chen] Ack [Sam Aldrin] This adds a lot of complexity. Why do we need to do this? Adding more labels is not the right solution. [Mach] The use case is for performance measurement of real traffic -- where you need to identify the path at the egress. [Sam] Who is encoding the label stack? [Mach] The ingress imposes, but the egress allocates it. You need a controller to allocate the labels here. If you want to solve this then you need additional labels. [Sam] What if you need performance data on the intermediate nodes? [Mach] It is for egress only. There are other solutions for the transit stats (not this draft) [Ketan Talaulikar] We should review the use cases in more depth to figure out where this is applicable, or required. Not required for delay measurement. You said that the Path Segment needs to be allocated from the SRGB or SRLB, but it is not clear why this is required? [Mach] You can get label from SRGB or SRLB [Ketan] Why not local label (outside SRGB or SRLB)? [Mach] We can just use a dynamic label at the egress. [Jeff Tantsura] Concerns about ability to support it across many platforms. [Mach] Since this is just at the egress, then the existing label stack has been popped already. [Jeff] Ericsson owns an IPR on this. [Ron Bonica] Given in SRv6 you don't POP labels, why do you do this? [Mach] Agree that this is not necessarily needed in SRv6, since we can use SRH to understand this. It's not hardware-friendly to use the SRH. The Path Segment would be an identifier. [Ron] The destination node can use this to reconstruct the label stack. Can't every node generate the whole label stack from the Path Segment -- didn't you just re-invent the RSVP-TE/LDP label? ---------------------- o TTL Procedures for SR-TE Paths - draft-arora-mpls-spring-ttl-procedures-srte-paths-00 - Shraddha Hegde 10 mins 9:55 [10:19] [Greg Mirsky] We have LSP ping for SR (8287). Section 5 explicitly discussed TTL handling for traceroute. Why do you think it's needed to have another document? Would it be good to update 8287? [Shraddha Hegde] RFC8287 is not very clear on PHP. Updating 8287 is logistics. [Lou Berger] Question as to whether this is SR-TE vs. just SR. [Shraddha] This is an issue where you have stacked labels. [Lou] There isn't a definition of SR-TE, which causes confusion. [Bruno] SR-TE is a stack of labels. [Lou] If this had said a stack of labels then there would be less confusion. [Shraddha] Definition for SRTE is not the objective of this draft. [Lou] So remove it [Bruno] We can say SR-policy instead. [] Question about the rule of not copying TTL from outer to inner label if outer TTL is greater (loop prevention). Is there any document specifying this? [Shraddha] It is a common/best practice. Not found in any RFC or draft. Even if you copy, traceroute would not work. [Sam Aldrin] The problem is real. When you send an Echo Request then the DDMAP is not necessarily there. Instead of DDMAP you might be better to encode into a new return code. [Shraddha] Thought about introducing new return code but concerned about backward compatibility issues ---------------------- o EPE OAM - draft-hegde-mpls-spring-epe-oam-00 - Shraddha Hegde 7 mins 10:05 Authors requested adoption [Zafar Ali] in peer mode sid. peer could be in different ASes. There is a problem with the encoding [Shraddha Hegde] You can group links and repeat. Not optimized [Zafar] May be cases where the local the interface might not be known to the sender. Ping may end in a different AS -- there might not be a reverse path. ---------------------- o LSP Ping/Traceroute for Segment Routing SIDs with MPLS Data Plane - draft-nainar-mpls-spring-lsp-ping-sids-00 - Zafar Ali 7 mins 10:12 [10:46] Will work with Shradda to see if we can collaborate or merge, as this is some overlap. ---------------------- o NSH and Segment Routing Integration for SFC - draft-guichard-spring-nsh-sr-00 - Jim Guichard 5 mins 10:19 [10:49] Authors requested WG adoption - but are OK to discuss in Prague. [Bruno] existing encaps for NSH in IPv6? Do you expect it to be different than SRv6? [Jim] No, no [Bruno] NSH encaps in IPv6/SRv6 better discussed in 6MAN [Jim] good point ---------------------- o BFD for Segment Routing Policies for TE - draft-ali-spring-bfd-sr-policy-02 - Zafar Ali 5 mins 10:24 [10:52] [Zafar] Skipped based on chairs discussion on merging with draft-mirsky. ---------------------- o OAM in Segment Routing Networks with IPv6 Data Plane - draft-ali-spring-srv6-oam-02 - Zafar Ali 5 mins 10:29 Requested adoption in SPRING. [Bruno] You can't self allocate code-points. [Zafar] We will need to respin the draft to replace with TBD. [Martin] You need to respin this draft rapidly because otherwise folks reading it will think that these code points are allocated. Please do this. [Zafar] We'll do this. [Greg Mirsky] Nice that you demonstrate that existing tools work. There is no need to use an O-bit [Zafar Ali] [Greg] If node has TTL expired you look into payload. If it has no TTL expiration, you don't look into O-bit (???) Suggest to remove O-bit from this document [Zafar] There are multiple use cases for O-bit. ... [Zafar] There is no need for the node processing TTL expiry to understand the SRH, there is detail in the document. The node generating the error will process and send back the packet. [Greg] Based on this, why do we need the O-bit? [Zafar] The O-bit means that we can do per-segment ping and traceroute. [Greg] OAM functionality is being defined in two places - both in the flag, and the UDP port. This causes confusion. Suggest that [the authors] read the document on iOAM that was published before Montréal. This removes the ambiguity. [Bruno] Please take this to the list. Greg, please start a mail on the list. [Greg] Glad that the O-bit has been removed. [Zafar] It hasn't been removed, just moved into the other draft. -- o Segment Routing Header Encapsulation for In-Situ OAM Data - draft-ali-spring-ioam-srv6-00 - Zafar Ali 10 mins 10:34 Skipped, out of time. o OAM for Service Programming with Segment Routing - draft-ali-spring-sr-service-programming-oam-00 - Zafar Ali 10 mins 10:44 Skipped, out of time. Speaker Shuffling Time 6 mins Total 120 mins