SPRING @IETF-114 Wednesday 27 July 2022 Chairs: Bruno Decraene James Guichard Joel Halpern Secretary: Shuping Peng ### SPRING Status - Chairs (10 min) {#spring-status---chairs-10-min} \*Due to the meetecho issue, the meeting was started 15 minutes late. \*The meetecho was off again about another 2 minutes. The allocated time for each presentation includes both presentation time and comment time. ### Circuit Style Segment Routing Policies (10 min) {#circuit-style-segment-routing-policies-10-min} Presenter: Christian Schmutzer (cschmutz@cisco.com) [draft-schmutzer-spring-cs-sr-policy][1] *The draft was changed from the pce to the spring working group: draft-schmutzer-spring-cs-sr-policy* Nitsan Dolev Elfassy (Ribbon Communications): How do we ensure protection with resource allocation? How to address bidirectional? Better to elaborate the two things. Christian Schmutzer: Bidirectional association to signal from both endpoints to PCE to indicate that both SR policies are associated with each other. PCE is to perform the computation. So the two SR policies are bidirectional and corouted. It is well-defined. Regarding the protection, two candidate paths work for the protection. Each has a bandwidth request. PCE will allocate both the working and the protection BW. Whenever we need to switch, the protection path will have the BW allocated. Zhenbin Li: Similar work like OAM protection and bidirectional SR path were considered several years ago, which developed the path segment work. There is relationship between these existing work and the current work. Hope the path segment work can be considered and combined with this work. Christian Schmutzer: Fair comment. Establishing an end-to end-path is a part of our work. We can discuss about how these two work are aligning. Dhruv Dhody: PCE is used extensively... (voice was cut off) Dhruv from the chatbox: This draft and presentation used PCE / PCEP extensively, is this applicable to BGP SR Policy as well or not? Jim Guichard: Please take any other questions to the mailing list. ### Path MTU (PMTU) for Segment Routing Policy (10 min) {#path-mtu-pmtu-for-segment-routing-policy-10-min} Presenter: Gyan Mishra (gyan.s.mishra@verizon.com) [draft-peng-spring-pmtu-sr-policy][2] Gyan Mishra: Feedback from the experts are appreciated. Joel Halpern: No time for questions. ### Connection-oriented Path in SRv6 Network (10 min) {#connection-oriented-path-in-srv6-network-10-min} Presenter: Zongpeng Du (duzongpeng@foxmail.com) [draft-du-spring-connection-oriented-srv6][3] Jim Guichard: No questions so we move on. ### Network Resource Partition Identifier (NRP-ID) in SRv6 segment (10 min) {#network-resource-partition-identifier-nrp-id-in-srv6-segment-10-min} Presenter: Yisong Liu (liuyisong@chinamobile.com) [draft-liu-spring-nrp-id-in-srv6-segment][4] Joel Halpern: As a participant, I like the general driver of this work. But the material must be clear about whether you are requiring/expecting a strict path or expecting intermediate nodes which are not addressed to extract the arguments from SIDs and handle them will be unusual requirement? We need to be clear about what we are doing. Yisong Liu: Thank you. Darren Dukes: Is the NRP-ID a hop by hop ID? Every SR or non-SR node does this stuff? Yisong Liu: Each non-SR node gets the NRP ID from the LSTP. ### Generalized Arguments of SRv6 Segment (10 min) {#generalized-arguments-of-srv6-segment-10-min} Presenter: Jianwei Mao(maojianwei@huawei.com) [draft-lm-spring-srv6-generalized-arguments][5] Jim Guichard: As an individual contributor, not clear what the features are? For example network slicing, why do you need to indicate this feature when you gona need more information? Consider the compression as well. How is the compression going to work with this? My concern is about something like the next flavor, if I have already used up all the bits, how am I gona do that? Jianwei Mao: We defined a new flavor to indicate the args needs to be processed as generalized arguments. The compression case has been considered, in the 6th page of the slides. Ketan Talaulikar: Have a concern on this notion of this generalized arguments. There is nothing in RFC8986. Whether it has arguments or not or whether it is valid is determined by the endpoint behavior definition of that SID. If anyone wants to use the arguments in a SID, there has to be endpoint behavior definition to indicate what the args are and how they are going to be processed. Maybe I am missing something very fundamental. It seems that generalized arguments is applicable for all SRv6 SIDs. Jianwei Mao: How to process the arguments as generalised arguments? We don't define new behavior but flavor to identify this SRv6 SID is carrying one generalized argument. Ketan: You need to define new codepoint. Let me see that. They don‘t apply to existing ones. We can discuss further in the list. Greg Mirsky: Not clear whether it is to define a behavior or capability advertisement. Not clear how Detnet is relevant to this? Jianwei Mao: We are defining for a general space for many features. Whether it is suitable for Detnet we can discuss further. Zhenbin Li: The args should be processed in the local node. The instructions to be processed by a specified segment could be multiple features. We need a structured template to be defined. We should refine the draft with usecases in more details. ### Redundancy Policy for Redundancy Protection (10 min) {#redundancy-policy-for-redundancy-protection-10-min} Presenter: Fan Yang (shirley.yangfan@huawei.com) [draft-geng-spring-redundancy-policy][6] Mike Koldychev: It would be better to replicate across candidate paths rather than the segment lists, you will not be able to have the load balancing anymore. Fan Yang: We will see further which solution is better for which scenarios. We can have more discussions in the mailing list. Israel Means: Please clarify about the Redundancy Binding SID and standard binding SID. Fan Yang: We have defined it in our previous draft. It should take all the semantics from the binding sid. So far it is the same. Greg Mirsky: The merging function works for packet-by-packet bases or flow bases? Fan Yang: It should be processed packet by packet. Greg Mirsky: Very similar to the definitions of the SIDs (replication and elimination) in Detnet. Better to align and share it with the Detnet WG. Fan Yang: We discussed about the relationship with Detnet before. We will further clarify in both the mailing list and draft in the future. ### Segment Routing for Enhanced DetNet (10 min) {#segment-routing-for-enhanced-detnet-10-min} Presenter: Xuesong Geng (gengxuesong@huawei.com) [draft-geng-spring-sr-enhanced-detnet][7] Greg Mirsky: What techniques do you use to guarantee the latency or jitter or any metric? Xuesong Geng: We go align with the definitions in Detnet. "Guarantee" in Detnet is to provide expected bounded latency. Greg Mirsky: You are right. In Detnet, there is no discussion of "Guarantee". The mechanisms discussed are TSN and PREOF. They can improve or reduce. But they provide no guarantee. Only time division multiplexing can provide guarantee. For the packet multiplexing there is no guarantee. Xuesong Geng: If there is no guarantee, we don't need to mention it. We can expect the max or min of the latency. Joel Halpern: The detailed definitions are set to be Detnet. This will not advance utill the Detnet stuff is adopted. We will leave Detnet to define the properties. For SPRING is how to indicate the Detnet properties in the segment list. Xuesong Geng: Agree. ### BGP Extensions of SR Policy for Segment List Identifier and Headend Behavior (5 min) {#bgp-extensions-of-sr-policy-for-segment-list-identifier-and-headend-behavior-5-min} Presenter: Hao Li (lihao@h3c.com) [draft-lin-idr-sr-policy-seglist-id][8] [draft-lin-idr-sr-policy-headend-behavior][9] Cheng Li: We already have similar definitions such as path segment. We could further discuss and cooperate to avoid any redundant work in IETF. Hao Li: ok. Ketan Talaulikar: SR Policy Yang model has a name for the segment list. That should be normally enough. Suggest to look at. As BGP SR Policy co-author, please bring this to IDR list to see whether we need to make any changes rather than bringing new documents. I believe that we have necessary things already there. If not please comment in the IDR mailing list. Hao Li: ok. ### Problem statement for Inter-domain Intent-aware Routing using Color (10 min) {#problem-statement-for-inter-domain-intent-aware-routing-using-color-10-min} Presenter: Shraddha Hegde (shraddha@gmail.com), Dhananjaya Rao [draft-hr-spring-intentaware-routing-using-color][10] *Sharddha was off, and Dhananjaya took over.* *The audio is breaking up.* Jim Guichard: Chairs want to see the front page is cleared up. Move some co-authors to contributors... Joel Halpern: Regarding the BGP protocol work, please go to the IDR group to join the discussions there. ## If time allows {#if-time-allows} * * * ### MPLS Extension Header Encodings (10 min) {#mpls-extension-header-encodings-10-min} Presenter: Rakesh Gandhi (rgandhi@cisco.com) [draft-jags-mpls-ext-hdr][11] Joel Halpern: Please go to the mailing list. Please engage. ### Encapsulation of BFD for SRv6 Policy (10 min) {#encapsulation-of-bfd-for-srv6-policy-10-min} Presenter: Yisong Liu (liuyisong@chinamobile.com) [draft-liu-bfd-srv6-policy-encap][12] *no time for this presentation* Speaker Shuffling Time/Buffer: 5 minutes Total Presentation Time: 115 minutes [1]: https://datatracker.ietf.org/doc/html/draft-schmutzer-spring-cs-sr-policy-02 [2]: https://datatracker.ietf.org/doc/draft-peng-spring-pmtu-sr-policy/ [3]: https://datatracker.ietf.org/doc/draft-du-spring-connection-oriented-srv6/ [4]: https://datatracker.ietf.org/doc/draft-liu-spring-nrp-id-in-srv6-segment/ [5]: https://datatracker.ietf.org/doc/draft-lm-spring-srv6-generalized-arguments/ [6]: https://datatracker.ietf.org/doc/draft-geng-spring-redundancy-policy/ [7]: https://datatracker.ietf.org/doc/draft-geng-spring-sr-enhanced-detnet/ [8]: https://datatracker.ietf.org/doc/draft-lin-idr-sr-policy-seglist-id/ [9]: https://datatracker.ietf.org/doc/draft-lin-idr-sr-policy-headend-behavior/ [10]: https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/ [11]: https://datatracker.ietf.org/doc/draft-jags-mpls-ext-hdr/ [12]: https://datatracker.ietf.org/doc/draft-liu-bfd-srv6-policy-encap/