IETF
spring
spring@jabber.ietf.org
Wednesday, July 27, 2022< ^ >
Meetecho has set the subject to: IETF-113
Room Configuration
Room Occupants

GMT+0
[13:51:56] <zulipbot> (Dhruv Dhody) Meetecho error
[13:52:09] <zulipbot> (Dhruv Dhody) Unexpected token < in JSON at position 0
please refresh the page and try again
[13:52:22] <zulipbot> (Lorenzo Miniero) @**Dhruv Dhody** yes we're aware, we're working on it
[14:00:53] <zulipbot> (Joel Halpern) And they are working on getting the meeting room open.  Necessary delay until they can.
[14:06:41] <zulipbot> (Boris Khasanov) Had the same issue as Dhruv
[14:07:31] <zulipbot> (Eduard V) Not all tools on the toolbar is visible. No video and audio
[14:08:03] <zulipbot> (Joel Halpern) Clearly, they are working on the room, but do not quite have it fixed yet.
[14:12:36] <zulipbot> (Lorenzo Miniero) The room should be open now, apologies again for the delay
[14:13:05] <zulipbot> (Dhruv Dhody) Woo hoo!
[14:13:26] <zulipbot> (Lorenzo Miniero) Note to chairs: you'll have to reload the materials from the UI and import slide decks you need, as unfortunately they were not imported automatically as we do when meetings start
[14:13:42] <zulipbot> (Lorenzo Miniero) We're preloading slides ourselves
[14:15:47] <zulipbot> (Joel Halpern) The chairs do not have the slides on our laptops.  Only on the meeting materials.  Do I need to manually download  them to make this work?
[14:16:54] <zulipbot> (Joel Halpern) A@meetecho nd now we lost room audio for remote attendees!!
[14:17:07] <zulipbot> (Lorenzo Miniero) Looking into this
[14:18:08] <zulipbot> (Cheng Li) broken once
[14:18:08] <zulipbot> (Eduard V) Hello
[14:18:24] <zulipbot> (Boris Khasanov) yes
[14:18:41] <zulipbot> (Eduard V) but nothing is visible
[14:18:54] <zulipbot> (Cheng Li) weird connection today.
[14:19:50] <zulipbot> (Stéphane Dodeller) now working better :-) video, sound and slides OK
[14:26:12] <zulipbot> (Nitsan Dolev Elfassy) How do you maintain the resources under protection (FRR etc) ?
[14:27:08] <zulipbot> (Nitsan Dolev Elfassy) Do we assume bi-directional connectivity ? what measures are applied to ensure the related resource guarantee?
[14:27:48] <zulipbot> (Joel Halpern) Note that the segment routing for enhanced detnet was uploaded as ppt.  We can not share ppt.  If I see the pdf in my email in time I will share it.  If not, we will skip that presentation.
[14:28:01] <zulipbot> (Vishnu Beeram) draft-schmutzer-spring-cs-sr-policy seems to be introducing a specific type of path-profile for SR policy paths. To be more precise, it is introducing "Bandwidth Constrained Bidirectional Co-routed Pinned Path SR policies" with restoration and/or reversion features enabled. I’m not sure if there is a need to standardize a term for a specific path profile. The notion of “Bandwidth Constrained Bidirectional Co-routed Pinned Path RSVP-TE Tunnels with restoration and/or reversion enabled” exists today – there is no IETF document that calls it Circuit Styled RSVP-TE Tunnel. So, not sure why we need to introduce a term for this profile now.
[14:29:12] <zulipbot> (Vishnu Beeram) Also it isn’t clear which of the various features that make up the above profile are mandatory – for example, if the paths aren’t co-routed, would the policy be no longer called a circuit styled SR policy?
[14:29:40] <zulipbot> (Xuesong Geng) @Joel, Thanks for reminding
[14:29:56] <zulipbot> (Xuesong Geng) I will send you a pdf version by email
[14:31:21] <zulipbot> (Jie Dong) It seems bandwidth guarantee is an important feature of a CS-SR Policy, the draft needs to clarify what are the possible mechanisms for bandwidth guarantee
[14:32:00] <zulipbot> (Ketan Talaulikar) @Pavan, I believe the "circuit style" is a short term for all of those. But better for the authors to clarify the mandatory characteristics. FWIW, a short term is preferable ;-)
[14:34:57] <zulipbot> (Antoine Fressancourt) Can chairs remind that Covid is airborne so masks should cover mouth AND nose please?
[14:35:28] <zulipbot> (Dhruv Dhody) It got to be chat today then -- My question was this draft and presentation used PCE / PCEP extensively, is this applicable to BGP SR Policy as well or not?
[14:37:49] <zulipbot> (Jie Dong) good question Dhruv
[14:38:47] <zulipbot> (Vishnu Beeram) @ Ketan -- okay with using a named path profile for ease of narrative. But, the issue with "standardizing" a profile name is that you would need to be very precise with what constitutes the specific profile.. Hope the next version clarifies that..
[14:38:47] <zulipbot> (Ketan Talaulikar) @Dhruv, yes, it would be applicable for BGP SR Policy as well. The model would be a controller driven work-flow.
[14:39:13] <zulipbot> (Ketan Talaulikar) @ Pavan +1
[14:40:57] <zulipbot> (Dhruv Dhody) Hoping the spring document is as general as possible and PCEP stuff can be moved to the PCE draft
[14:41:10] <zulipbot> (Vishnu Beeram) @ Dhruv +1; the PCEP references can be removed from the document..
[14:46:08] <zulipbot> (Louis Chan) How about if the intermediate node performs binding sid conversion and lengthen the header length?
[14:46:08] <zulipbot> (Shraddha Hegde) why not just set the PMTU to lowest link mtu for all policies. Not sure all the complexity is justified given that you cant be accurate all the time
[14:46:21] <zulipbot> (Cheng Li) well, I was dropped off from the queue
[14:46:36] <zulipbot> (Cheng Li) one comment for the PMTU draft.
[14:46:49] <zulipbot> (Anthony Somerset) kindly request the speaker speak up or move microphone closer
[14:47:20] <zulipbot> (Louis Chan) Agree..the PMTU notation is a bit complex in practical situation
[14:47:46] <zulipbot> (Ketan Talaulikar) @Shraddha, that is a fair question and perhaps some operators will do just that. However, I understand that some vendors/operators wish to do more precise computation and hence the need to clarify at least what PMTU means and how it is going to be used.
[14:48:12] <zulipbot> (Dhruv Dhody) @Shraddha PMTU for sr-policy is an adopted item in both IDR and PCE WG, the purpose of this I-D in spring was to be as clear as possible on what we mean by the PMTU in case of SR-MPLS and SRv6
[14:48:13] <zulipbot> (Cheng Li) Thank you for the authors for proposing the draft. We have done some BGP/PCE/IGP extensions already, and this was asked by Ketan long time ago, finally it is here. Thank you for Kentan and authors. Hope all the drafts can be moved forward ASAP to help the implementation and deployment.
[14:48:52] <zulipbot> (Boris Khasanov) @Gyan - will PMTU draft require the update of recent RFC 9256?
[14:49:46] <zulipbot> (Tony Li) Trying to manage a network with non-uniform MTUs would be... exceedingly challenging. Is this really worth the effort?
[14:49:59] <zulipbot> (Ketan Talaulikar) @Boris, I don't think so. I do foresee more things getting added on top of the base SR Policy architecture. As long as it is not changing the base, I believe it is not an "update".
[14:49:59] <zulipbot> (Dhruv Dhody) I see it as an extension not really an update! Is there any text in RFC 9256 that needs changing?
[14:50:38] <zulipbot> (Ketan Talaulikar) @Tony, perhaps not. Some folks still want to and the specification is just to clarify that.
[14:50:51] <zulipbot> (Andrew Stone) @Nitsan - related/bidirectional resource guarantee: rfc9059
@Pavan - Agree with your summary, that it's essentially a flavour of a tunnel profile. I think key thing is that the document is describing the combination of elements already defined in IETF, or newly defined (i.e new PCEP extensions), in an information track document so that the terminology can be consistent, and the combination of these building blocks can be well-known, which would allow the new extensions to have a backing use case description.
@Jie - could you expand a bit more? Do you mean, for example, a statement describing something such as the PCE may leverage mechanisms such as GRPC to do bandwidth tracking?
@Dhruv - Yes, current focus is PCEP. In theory, some concepts of CS-SR Policy could be deployed via BGP, but main focus is to use the foundation already supported and defined in PCEP.
[14:51:30] <zulipbot> (Christian Schmutzer) @ pavan, +1 we will clarify mandatory requirements in future versions of the draft
[14:53:35] <zulipbot> (Dhruv Dhody) on slide 6, if you are using list of node SID to "simulate RSVP" how do they bind it to the adjacency?
[14:53:48] <zulipbot> (Tony Li) Audio is clipping badly.
[14:54:41] <zulipbot> (Jie Dong) @Andrew - this is related to the discussion in the SPRING list, Sasha raised a question on how the bandwidth can be guaranteed for CS-SR policy, Christian mentioned one  option of allocating dedicated traffic class and queue for CS-SR, and I mentioned another mechanism based on resource-aware SID defined in draft-ietf-spring-resource-aware-segments
[14:55:23] <zulipbot> (Dhruv Dhody) What is the usecase of having NRP-ID per SID?
[14:56:02] <zulipbot> (Ketan Talaulikar) @Dhruv, +1, good Q.
[14:56:18] <zulipbot> (Acee Lindem) I'm feeling a bit of deja vu - wasn't there a presentation last year with a different slice acronym?
[14:56:34] <zulipbot> (Eduard V) How to be sure that ARG has NRP-ID, not some garbage?
[14:57:39] <zulipbot> (Ketan Talaulikar) @Eduard, a SRv6 Endpoint Behavior definition needs to specify an ARG for it to be used. That definition needs to say what is a valid or invalid ARG.
[14:58:34] <zulipbot> (Daniel Bernier) @Dhruv, agreed I would have thought of using the TAG field since potentially all sids in the list would be in the same "slice" or "construct" (afraid of over abusing of the term slice here)
[14:59:00] <zulipbot> (Louis Chan) Please also check out draft-chan-spring-srv6-sub-slice-00. This draft puts slice info just next to locator. The benefit is to use LPM (longest prefix match) in normal routing to steer traffic into different tunnels (thus slice)
[15:01:11] <zulipbot> (Cheng Li) hope the speakers can check the audio before the meeting to avoid unstable audio connection.
[15:01:40] <zulipbot> (Darren Dukes) So is nrp-Id a hop by hop id?
[15:01:58] <zulipbot> (Cheng Li) if putting in the SID, it will be a per segment term/
[15:02:11] <zulipbot> (Zafar Ali) @**Vishnu Beeram**  Authors can add the specific definition in the terminology section
[15:04:05] <zulipbot> (Eduard V) @Ketan, the previous presented assumed that MPLS label stack is inside ARG. Some frag is needed to understand for what ARG is used
[15:04:18] <zulipbot> (Fan Yang) @Daniel in I-D-ietf-sr-redundancy-protection,TAG field is proposed to carry the sequence number for redundancy protection. I wonder whether there was previous discussions on how to use Tag field in SPRING?
[15:05:55] <zulipbot> (Ketan Talaulikar) @Eduard, there cannot be any assumptions related to ARGs. It has to be specified precisely. Perhaps we wait for the authors to clarify in the further versions.
[15:05:55] <zulipbot> (Vishnu Beeram) @ Darren -- The NRP indicator in the packet is meant to be used to identify the specific forwarding treatment to be given to the packet.. the authors of the draft seem to be (guessing here) talking about a use-case where there could be different treatment per segment..
[15:07:56] <zulipbot> (Daniel Bernier) I have a funny deja-vu feeling of NSH metadata type-I or type-II
[15:12:23] <zulipbot> (Yisong Liu) @Darren nrpid in arg can be different in each endpoint  , but in the non-endpoint (maybe SRv6 node ,maybe non-SRv6 node)can only check the LSPT to get NRP-ID of the next endpoint
[15:14:20] <zulipbot> (Eduard V) 3 proposition on how to abuse ARG are not compatible with Compressed SID. These bits are already used.
[15:16:06] <zulipbot> (Yisong Liu) @Eduard Thank you for your comments, we'll do further analysis to find a way to solve the problem with compressed SID
[15:17:12] <zulipbot> (Dhruv Dhody) redundancy-protection is for SRv6 only, is there an SR-MPLS equivalent?
[15:18:44] <zulipbot> (Eduard V) @Yisong Liu: some signalling is needed (flag? TLV?) to point what is inside ARG. Other drafts propose completely different things.
[15:21:45] <zulipbot> (Darren Dukes) Tisong, there is no problem to solve.
[15:22:11] <zulipbot> (Yisong Liu) @Eduard: in the solution, must advertise or configure LSPT for non-endpoint, so I think no need flags or TLVs to identify
[15:23:08] <zulipbot> (Cheng Li) +1 @Darren Dukes
[15:24:00] <zulipbot> (Dan Voyer) @Tisong I wonder if you can cover benefits/what you can do with your approach that other approach can't do for next version of your draft ?
[15:24:14] <zulipbot> (Ketan Talaulikar) @Eduard, per RFC8986, the SRv6 Endpoint Behavior (it is a code point) is what is to be used for signaling the applicability of the ARGs.
[15:27:00] <zulipbot> (Cheng Li) what is the progress of Detnet right now? long time no hear the news of Detnet.
[15:27:31] <zulipbot> (Yisong Liu) @Dan we just provide one alternative way for encoding the NRP ID, but thank you for your comments we'll consider what are the benefits of our solution.
[15:29:33] <zulipbot> (Eduard V) @Ketan, thanks. Understood, control plane would help to understand what SID has what structure in the ARG.
[15:31:29] <zulipbot> (Dhruv Dhody) Can there be more than one BLI applicable at the same time?
[15:32:13] <zulipbot> (Ketan Talaulikar) @Eduard, the structure of SID is one aspect - it doesn't define anything about the ARG (or its "structure"). The use of ARGs needs to be in the behavior definition (perhaps include any of its "structure"). I hope I got that across right ;-)
[15:32:53] <zulipbot> (Fan Yang) @Cheng Li redundancy protection is triggered and inspired by DetNet PREOF, but used as a generazlied protection mechanism. This was the agreement reached in previous discussions.   If necessary, we are happy to present it in DetNet.
[15:33:41] <zulipbot> (Cheng Li) thank you! good to know the progress.
[15:35:29] <zulipbot> (Eduard V) @Ketan. Could I assume that to transfer "type/structure of ARG for this SID" in the control plane, ISIS and OSPF would need additional extensions?
[15:36:01] <zulipbot> (Cheng Li) we can not hear anything...
[15:36:01] <zulipbot> (Fan Yang) @Dhruv good catch. redundancy protection should cover both SR-MPLS and SRv6, so does redundancy policy. However,  currently SR MPLS has no programming capabilities, so only SRv6 for redundancy protection is covered. I agree it is missing in SR-MPLS.
[15:36:14] <zulipbot> (Ketan Talaulikar) @Eduard, yes. Unless it is something that gets codified in the specification of that behavior.
[15:37:40] <zulipbot> (Eduard V) @Ketan, the second option is to announce it in the TLV or flag. It is more SRsh (more information in the data plane, less in the control plane). I am not sure that it is better.
[15:39:29] <zulipbot> (Dhruv Dhody) For what its worth in PCEP via we have a similar ID called path-ID in PATH-ATRIB Object [https://www.ietf.org/archive/id/draft-ietf-pce-multipath-06.html#section-4.2]
[15:42:56] <zulipbot> (Yisong Liu) @Eduard @Ketan in the proposal the SRv6 node will advertise slice prefix and corresponding NRP ID position, I think it is not neccesary to announce the ARG behavior with flags or TLVs again
[15:45:19] <zulipbot> (Ketan Talaulikar) @Eduard, I wouldn't call that SRsh. There is a cost to any/all things that need to be implemented in the dataplane. So I am in favor of control plane here.
[15:46:01] <zulipbot> (Jeff Tantsura) +1 Ketan
[15:47:39] <zulipbot> (Eduard V) @Ketan: Thanks a lot for this education!
[15:51:05] <zulipbot> (Tony Li) Audio is breaking up.
[15:51:52] <zulipbot> (Cheng Li) As a Internet conference, we may provide a better internet connection for our meeting firstly :)
[15:52:06] <zulipbot> (Cheng Li) an Internet
[15:52:19] <zulipbot> (Tony Li) I suspect some of it is on the speaker's end.
[15:52:32] <zulipbot> (Ketan Talaulikar) "dogfooding" :-)
[15:53:28] <zulipbot> (Mengxiao Chen) @Dhruv: Thank you for your information. That’s very helpful. I think the extension in BGP should use PCEP as a reference.
[15:54:21] <zulipbot> (Kentaro Ebisawa) We need "IETF meeting quality access line" in every country. :)
[15:54:50] <zulipbot> (Cheng Li) +1 @Kentaro Ebisawa
[15:55:47] <zulipbot> (Louis Chan) voice quality issue.....a typical case that a doctor can't heal himself
[15:58:09] <zulipbot> (Anthony Somerset) low quality headset mics often mangle the quality which gets made worse over lossy links - kudos to the presenter that had a proper podcast mic for his presentation - the audio quality was crystal clear for us in the room