SPRING WG - Source Packet Routing in Networking Chairs: Bruno Decraene James Guichard Joel Halpern Secretary: Shuping Peng =============================================================================== Monday, 12:00-14:00, November 8, 2021 (UTC) o SPRING Status [ 5 minutes ] Chairs Joel Halpern presented. The issue tracker for the adopted compression document will be on the Github. Srihari Sangli (from the Chat Panel): Should 6man bless the document? c-sid and its relationship to RFC4291. Joel Halpern: The 6man will decide the relationship. o Enhanced Performance Measurement Using Simple TWAMP in Segment Routing Networks [ 10 minutes ] draft-gandhi-spring-enhanced-srpm Rakesh Gandhi Greg Mirsky: It enables one way measurement. The reflector doesnot have a state, and the packet does not leave the data plane. The format of the reflected packet is different from the format of the packet received from the sender. How you can simply swap the source and destination address of the two packets? Also if you dont have state in the reflector you cannot measure one way but only round trip. It is not accurate. I think some serious problem with this. Rakesh Gandhi: Thanks. The loopback measurement mode has been defined in a working group document. Please have a look at the draft and let us know. That is for the round trip delay. This is an optimization where the session reflector using the network programming function as the receiver timestamp. This is explained in the enhanced loopback mode draft. Please have a look and let us know about your comments. Greg Mirsky: I sent comments before the meeting. I see contradiction between the statements. SR programming does not introduce any special mode in the stamp. The reflector has to be stateful for the one way measurement. The underlay for the packet encapsulation is not really relevant. We can continue in the mailing list. Rakesh Gandhi: I will look at your recent email and reply. Stewart Bryant: How do you avoid the ECMP issue with this? The ECMP will give you a different answer when you run this. Is ECMP safe? Is it for MPLS? Rakesh Gandhi: For ECMP there are standard techniques for example using the Entropy label. Stewart Bryant: You require the Entropy label for the ECMP safe measurement that is absolutely fine, but you must show it. Currently it is not. Rakesh Gandhi: We will add it. Stewart Bryant: It has to be high level required because people will get the wrong answer. You cannot publish a document where people get the wrong answer. Rakesh Gandhi: Good comment. We will add it. Andrew Alston: What is the impact on the BCP38? The incorrect sender and receiver. That reversal of addresses does kind of worry me. Would like to hear your thoughts on the impacts on things like BCP38 and anti-spoofing protection. Rakesh Gandhi: If that is not suitable for the network, so the second method for the reverse path can be SR-MPLS. The full label stack could be used to bring the packet back to the sender. Both methods have been defined depending on the deployment. One of them can be selected. There are already many RFCs around about using the swapping of the source address. It is no difference here. Joel Halpern: Please continue email discussions. o Segment Routing for End-to-End IETF Network Slicing [ 10 minutes ] draft-li-spring-sr-e2e-ietf-network-slicing Yongqing Zhu Vishnu Beeram: Slide 3 that showed all the relevant drafts. We have a WG draft on framework which stated ietf network slices, and we don't limit the scope of that draft. It would be good to limit the scope of this draft on how to stitch multiple vtns together. Jie Dong: The related framework draft of this draft will be presented tomorrow in teas. This draft is more about SR based extension to solve the multi-domain mapping and concatenation. Adrian Farrel: Speaking as the editor of the network slicing framework draft in teas which is intended to be sort of all embracing for ietf network slices. I want to caution the authors here to be very careful about the term end-to-end. It has been used by 3GPP. The IETF network slice is only a part. The concept of end has a strange meaning in IETF. Maybe step back from the headline title of end-to-end and talk more about what you want to achieve, rather than get hooked on the terminology. o SRv6 inter-domain mapping SIDs [ 10 minutes ] draft-salih-spring-srv6-inter-domain-sids Salih K A Zhenbin Li: End.replace is similar to swap of MPLS. In SRv6 we don't need SWAP. Why to introduce this SID. Salih: It is for multi-domain. On the boarder node, it is for option C and uses BGP. Ketan Talaulikar: End.DB6, service SID is per prefix or per VRF. Salih: Per prefix. It is option B. Ketan Talaulikar: Please clarify in the draft. Also, suggest to consider per VRF instead. Salih: Sure. Cheng Li: Don't understand why to replace the destination address. 2. When the SID list contains one SID like BSID, what is difference between the BSID and End.replace. The procedure is the same. Salih: If it is multiple SIDs to reach the other domain. It will be based on the situation. We will update the draft with more details. Zhenbin Li: The purpose of this type of SID. It is different from MPLS and SRv6. IPv6 can reduce using aggregation. It is reducing the benefits of SRv6. Salih: Different scenarios. It is for multiple domains and it is option C. It could be multiple intent-based path. Different mechanisms for different scenarios. Shraddha Hegde (from the chat box): This mechanism is for loosely coupled domains where aggregation is not possible. Darren Dukes: Additional discussion of how an SR Source uses SIDs of these behaviors and will be interesting to see in subsequent versions. Salih: Will update the draft. Shaofu Peng: END.Replace seems enough why we need END.ReplaceB6? Salih: In the diagram you can see that cross areas you need multiple SIDs in the SRH and that is why you need to push an additional SRH at the corresponding ingress boarder nodes. It will be clear with an example when we mention it in the draft. Cheng Li (from the chat box): Better to clarify why we need these new behavious why not the existing ones. o SRH encapsulation for Alternate Marking Method [ 10 minutes ] draft-fz-spring-srv6-alt-mark Giuseppe Fioccola Ron Bonica: Why would you not to make it more general, and make it work for any other routing header? Giuseppe: Just to leverage this capability of SRH to be extended to TLV. The solution for all the routing header is already in the 6man draft. There we define the DOH that can be applicable to all the routing header. It can be an optimized solution only for SRH. Ron Bonica: It seems a second solution for the problem you have already solved. Tianran Zhou (from the chat box): The generic way is defined in 6man. This is only an optimization for SRH. Joel: Please continue in the mailing list. o A Simplified Scalable ELAN Service Model with Segment Routing Underlay [ 10 minutes ] draft-boutros-spring-elan-services-over-sr Sami Boutros Éric Vyncke: Your draft and your slides got a section about IPv4 arp but nothing about v6 NDP. Will add support for IPv6 support later? Sami: Yes, will add later. Matthew Bocci: Relationship with the draft in BESS? Clarify your intention of the BESS draft. This relates to BGP signalings and it should really live in BESS. Sami: The concept is more segment routing so we present the concept here in SPRING. The signaling details will be in BESS. Here is more about the concept and the architecture. Will clarify in the later version. Joel Halpern: The Chairs will coordinate to make sure that the right materials are discussed in the right WG. Patrice Brissette: The same comment to Matthew. Is it any difference between there two drafts? Sami: No, not right now. Will change the other draft to more signaling aspects in the later version. o Intent-based Routing [ 10 minutes ] draft-li-teas-intent-based-routing Zhenbin Li Linda Dunbar: Is that intent perform the similar function to QoS / Policy in a way that you can steer traffic and give another layer of policy matching criteria? Zhenbin Li: To some extent, it is similar. To be more exact, it is like color, such as low latency or high bandwidth, not only just like DSCP which is just a codepoint. It is a abstract of the requirements. Not a detailed service requirement. Eric Vyncke (from the chat box): please specify whether the IPv6 Dest Options should be BEFORE or AFTER the routing header. o Source Segment for Multicast Source Routing over IPv6 [ 10 minutes ] draft-xl-msr6-source-segment Xuesong Geng Ron Bonica: What happens if a packet has a SID as its source address but for some reasons the packet can not be forwarded, and the node cannot forward it sends an ICMP message to that source address. What does the ICMP message go? Xuesong: The source address is still routable. The locator part is still routable. Just the MVPN information can be carried in the Argument part. Ron Bonica: So lower bits are totally ignored at the source. Joel: This is a detailed discussion. Please go to the mailing list. Zhaohui Zhang: This concept was first brought up in BIER. There were a lot of discussions in the mailing list. Xuesong: It is not for BIER. This can be used for any IPv6 based multicast scenarios to carry mvpn. We also discussed this in the section 6 in the document. Please review the draft. o Functional Addressing (FA) for internets with Independent Network Address Spaces (IINAS) [ 10 minutes ] draft-eckert-intarea-functional-addr-internets Toerless Eckert Joel: It is very questionable whether it is within the charter of SPRING. Take care! Stay well! Speaker Shuffling Time/Buffer: 5 minutes Total Presentation Time: 85 minutes