Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi, I'm fine with the below. Do folks have any concerns with the below, or can I update the draft? Please speak up if you disagree. thanks, Peter On 12/05/2021 17:33, Les Ginsberg (ginsberg) wrote: Alvaro (and everyone) - I think we can do better than this. Prefix-attributes sub-TLV is necessary when a prefix is leaked between levels - and more specifically when leaked upwards in the hierarchy. (We have the "D" bit in the TLV itself when leaked downwards.) While I would prefer that we simplify things and simply require the sub-TLV all the time, I think we can be more generous and still be functional. 1)Prefix-attributes SHOULD be included in Locator TLV 2)Prefix-attributes MUST be included when TLV is leaked upwards in the hierarchy 3)Prefix-attributes sub-TLV MUST be included when the advertisement is "redistributed" from another protocol Note that because the sub-TLV is not mandatory, if #2 and #3 are NOT followed, receivers will be unable to determine the correct source of the advertisement and may do the "wrong thing". And the receivers will be unable to detect the violation. Finally, RFC 7794 was published over 5 years ago. Vendors make their own choices as to what protocol extensions they choose to support. But given the usefulness of the information in prefix-attributes sub-TLV I would encourage implementations which do not yet support the sub-TLV to add it. Les -Original Message- From: Alvaro Retana Sent: Wednesday, May 12, 2021 7:17 AM To: Gengxuesong (Geng Xuesong) ; Peter Psenak (ppsenak) ; bruno.decra...@orange.com Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) ; draft-ietf-lsr-isis-srv6- extensi...@ietf.org; Les Ginsberg (ginsberg) ; Shraddha Hegde ; lsr@ietf.org; cho...@chopps.org Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Peter: Hi! As Xuesong suggested earlier, could you/we live with “SHOULD send”? The mitigating circumstance (recommend vs require) is precisely the lack of support. I think your original reply to Gunter about how it could be hard to mandate the Flags TLV at this point is spot on. Thanks! Alvaro. On May 12, 2021 at 4:49:58 AM, Peter Psenak wrote: as I said, if we want to mandate the presence of the Prefix Attribute sub-TLV, we MUST ignore Locators without it. If we don't, then the MUST on the originator does not mean anything. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Alvaro (and everyone) - I think we can do better than this. Prefix-attributes sub-TLV is necessary when a prefix is leaked between levels - and more specifically when leaked upwards in the hierarchy. (We have the "D" bit in the TLV itself when leaked downwards.) While I would prefer that we simplify things and simply require the sub-TLV all the time, I think we can be more generous and still be functional. 1)Prefix-attributes SHOULD be included in Locator TLV 2)Prefix-attributes MUST be included when TLV is leaked upwards in the hierarchy 3)Prefix-attributes sub-TLV MUST be included when the advertisement is "redistributed" from another protocol Note that because the sub-TLV is not mandatory, if #2 and #3 are NOT followed, receivers will be unable to determine the correct source of the advertisement and may do the "wrong thing". And the receivers will be unable to detect the violation. Finally, RFC 7794 was published over 5 years ago. Vendors make their own choices as to what protocol extensions they choose to support. But given the usefulness of the information in prefix-attributes sub-TLV I would encourage implementations which do not yet support the sub-TLV to add it. Les > -Original Message- > From: Alvaro Retana > Sent: Wednesday, May 12, 2021 7:17 AM > To: Gengxuesong (Geng Xuesong) ; Peter > Psenak (ppsenak) ; bruno.decra...@orange.com > Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) > ; draft-ietf-lsr-isis-srv6- > extensi...@ietf.org; Les Ginsberg (ginsberg) ; > Shraddha Hegde ; lsr@ietf.org; > cho...@chopps.org > Subject: Re: [Lsr] Last Call: > (IS-IS > Extension to Support Segment Routing over IPv6 Dataplane) to Proposed > Standard > > Peter: > > > Hi! > > As Xuesong suggested earlier, could you/we live with “SHOULD send”? > The mitigating circumstance (recommend vs require) is precisely the > lack of support. I think your original reply to Gunter about how it > could be hard to mandate the Flags TLV at this point is spot on. > > Thanks! > > Alvaro. > > > > On May 12, 2021 at 4:49:58 AM, Peter Psenak wrote: > > > as I said, if we want to mandate the presence of the Prefix Attribute > > sub-TLV, we MUST ignore Locators without it. If we don't, then the MUST > > on the originator does not mean anything. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Les, I don't agree with mandating prefix attributes sub-TLV in locator TLV at this stage of publication when there are multiple implementations that don't originate it. There are usecases that can be deployed without prefix attributes sub-TLV. I propose that we clarify the specific usecases that require prefix attributes sub-TLVs to be associated with locator TLV. For example, we should add the TI-LFA with leaked locators across multiple levels that Gunter pointed out, and add a statement that prefix attributes sub-tlv SHOULD be originated in locator TLV for this usecase to be supported. Rgds Shraddha Juniper Business Use Only From: Les Ginsberg (ginsberg) Sent: Wednesday, May 12, 2021 3:59 AM To: Shraddha Hegde ; Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org; Gengxuesong (Geng Xuesong) Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: RE: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard [External Email. Be cautious of content] Shraddha/ Xuesong - Since Prefix Attributes sub-TLV is required for correct operation when a Locator is leaked, would it be safe to assume that your implementations either do not leak Locators or you advise your customers not to deploy this feature with multiple levels? The problem with allowing the sub-TLV to be optional is that if the sub-TLV is omitted you cannot tell whether the Locator has been leaked - so you don't know whether you have a problem or not. The safest thing to do is require prefix-attributes sub-TLV always - then you can guarantee that if the prefix is leaked the necessary information will be present. Anything else leaves us vulnerable. We all appreciate interoperability considerations, but frankly this is a gap that needs to be closed to support correct operation. Les From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde Sent: Tuesday, May 11, 2021 8:21 AM To: Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Juniper has an implementation of SRv6 that does not support Prefix attributes sub-tlv in locator TLV. We would prefer not to change the optional sub-TLV to MUST. Rgds Shraddha Juniper Business Use Only From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Alvaro Retana Sent: Friday, May 7, 2021 7:23 PM To: Peter Psenak mailto:ppse...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard [External Email. Be cautious of content] On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Peter: Hi! As Xuesong suggested earlier, could you/we live with “SHOULD send”? The mitigating circumstance (recommend vs require) is precisely the lack of support. I think your original reply to Gunter about how it could be hard to mandate the Flags TLV at this point is spot on. Thanks! Alvaro. On May 12, 2021 at 4:49:58 AM, Peter Psenak wrote: > as I said, if we want to mandate the presence of the Prefix Attribute > sub-TLV, we MUST ignore Locators without it. If we don't, then the MUST > on the originator does not mean anything. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Bruno, On 12/05/2021 10:43, bruno.decra...@orange.com wrote: Hi Peter, From: Peter Psenak [mailto:ppse...@cisco.com] Hi Bruno, On 12/05/2021 10:24, bruno.decra...@orange.com wrote: Hi Peter, Thanks for the answer. Please see inline. From: Peter Psenak [mailto:ppse...@cisco.com] Hi Bruno, On 12/05/2021 09:51, bruno.decra...@orange.com wrote: Hi Xuesong, Clarification question: are you talking about interoperability (between two nodes) or compliancy (between an implementation and the RFC)? I'm afraid the two are related. If we mandate the Prefix Attribute Sub-TLV inside the Locator TLV, we would have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored. Mandating the advertisement is one thing (if it's useful, not to mention required, let's advertise it). Then why would we have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current spec allows for both (presence & non-presence), no? That seem like an error handling situation that we can choose. if we mandate something we need to say what happens when the mandated data is not present Absolutely. I could not agree more. I call this error handling. - typically we ignore. OK, but here we seem free to define "whatever" error handling we want since current version of the draft allows for both presence or non-presence. as I said, if we want to mandate the presence of the Prefix Attribute sub-TLV, we MUST ignore Locators without it. If we don't, then the MUST on the originator does not mean anything. thanks, Peter Thanks, --Bruno If we don't ignore, then we are not really mandating it. thanks, Peter Thanks for the discussion, --Bruno As a result, implementations that do not send the Prefix Attribute Sub-TLV would not just be not compliant, but would also not interoperate with the ones that follow the specification. thanks, Peter If the former, could you please spell out the interop issue? Thanks, Best regards, --Bruno *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong (Geng Xuesong) *Sent:* Wednesday, May 12, 2021 9:16 AM *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde ; Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Les, Prefix Attributes sub-TLV is necessary when locator is leaked. So we are not against Prefix Attribute sub-TLV implementation. We just propose to keep it optional (“should” rather than “must”) for interoperability. Best Xuesong *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] *Sent:* Wednesday, May 12, 2021 6:29 AM *To:* Shraddha Hegde mailto:shraddha=40juniper@dmarc.ietf.org>>; Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org>; Gengxuesong (Geng Xuesong) mailto:gengxues...@huawei.com>> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> *Subject:* RE: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Shraddha/ Xuesong – Since Prefix Attributes sub-TLV is required for correct operation when a Locator is leaked, would it be safe to assume that your implementations either do not leak Locators or you advise your customers not to deploy this feature with multiple levels? The problem with allowing the sub-TLV to be optional is that if the sub-TLV is omitted you cannot tell whether the Locator has been leaked – so you don’t know whether you have a problem or not. The safest thing to do is require prefix-attributes sub-TLV always – then you can guarantee that if the prefix is leaked the necessary information will be present. Anything else leaves us vulnerable. We all appreciate interoperability considerations, but frankly this is a gap that needs to be closed to support correct operation. Les *From:*Lsr mailto:lsr-boun...@ietf.org>> *On Behalf Of *Shraddha Hegde *Sent:* Tuesday, May 11, 2021 8:21 AM *To:* Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane)
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Peter, > From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > On 12/05/2021 10:24, bruno.decra...@orange.com wrote: > > Hi Peter, > > > > Thanks for the answer. > > Please see inline. > > > >> From: Peter Psenak [mailto:ppse...@cisco.com] > >> > >> Hi Bruno, > >> > >> > >> On 12/05/2021 09:51, bruno.decra...@orange.com wrote: > >>> Hi Xuesong, > >>> > >>> Clarification question: are you talking about interoperability (between > >>> two nodes) or compliancy (between an implementation and the RFC)? > >> > >> I'm afraid the two are related. If we mandate the Prefix Attribute > >> Sub-TLV inside the Locator TLV, we would have to say that the Locator > >> TLV without the Prefix Attribute Sub-TLV MUST be ignored. > > > > Mandating the advertisement is one thing (if it's useful, not to mention > required, let's advertise it). > > Then why would we have to say that the Locator TLV without the Prefix > Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current > spec allows for both (presence & non-presence), no? That seem like an error > handling situation that we can choose. > > if we mandate something we need to say what happens when the mandated > data is not present Absolutely. I could not agree more. I call this error handling. >- typically we ignore. OK, but here we seem free to define "whatever" error handling we want since current version of the draft allows for both presence or non-presence. Thanks, --Bruno > If we don't ignore, then we > are not really mandating it. > > thanks, > Peter > > > > > > Thanks for the discussion, > > --Bruno > > > >> As a result, > >> implementations that do not send the Prefix Attribute Sub-TLV would not > >> just be not compliant, but would also not interoperate with the ones > >> that follow the specification. > >> > >> thanks, > >> Peter > >> > >>> > >>> If the former, could you please spell out the interop issue? > >>> > >>> Thanks, > >>> > >>> Best regards, > >>> > >>> --Bruno > >>> > >>> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong > >>> (Geng Xuesong) > >>> *Sent:* Wednesday, May 12, 2021 9:16 AM > >>> *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde > >>> ; Alvaro Retana > >>> ; Peter Psenak (ppsenak) > >> ; > >>> lsr@ietf.org > >>> *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; > >>> Van De Velde, Gunter (Nokia - BE/Antwerp) > >> > >>> *Subject:* Re: [Lsr] Last Call: > >>> (IS-IS Extension to Support > >>> Segment Routing over IPv6 Dataplane) to Proposed Standard > >>> > >>> Hi Les, > >>> > >>> Prefix Attributes sub-TLV is necessary when locator is leaked. > >>> > >>> So we are not against Prefix Attribute sub-TLV implementation. We just > >>> propose to keep it optional (“should” rather than “must”) for > >>> interoperability. > >>> > >>> Best > >>> > >>> Xuesong > >>> > >>> *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > >>> *Sent:* Wednesday, May 12, 2021 6:29 AM > >>> *To:* Shraddha Hegde >>> <mailto:shraddha=40juniper@dmarc.ietf.org>>; Alvaro Retana > >>> mailto:aretana.i...@gmail.com>>; Peter > Psenak > >>> (ppsenak) mailto:ppse...@cisco.com>>; > >> lsr@ietf.org > >>> <mailto:lsr@ietf.org>; Gengxuesong (Geng Xuesong) > >>> mailto:gengxues...@huawei.com>> > >>> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; > >>> draft-ietf-lsr-isis-srv6-extensi...@ietf.org > >>> <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, > >>> Gunter (Nokia - BE/Antwerp) >>> <mailto:gunter.van_de_ve...@nokia.com>> > >>> *Subject:* RE: [Lsr] Last Call: > >>> (IS-IS Extension to Support > >>> Segment Routing over IPv6 Dataplane) to Proposed Standard > >>> > >>> Shraddha/ Xuesong – > >>> > >>> Since Prefix Attributes sub-TLV is required for correct operation when a > >>> Locator is leaked, would it be safe to assume that your implementations > >>> eith
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Bruno, On 12/05/2021 10:24, bruno.decra...@orange.com wrote: Hi Peter, Thanks for the answer. Please see inline. From: Peter Psenak [mailto:ppse...@cisco.com] Hi Bruno, On 12/05/2021 09:51, bruno.decra...@orange.com wrote: Hi Xuesong, Clarification question: are you talking about interoperability (between two nodes) or compliancy (between an implementation and the RFC)? I'm afraid the two are related. If we mandate the Prefix Attribute Sub-TLV inside the Locator TLV, we would have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored. Mandating the advertisement is one thing (if it's useful, not to mention required, let's advertise it). Then why would we have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current spec allows for both (presence & non-presence), no? That seem like an error handling situation that we can choose. if we mandate something we need to say what happens when the mandated data is not present - typically we ignore. If we don't ignore, then we are not really mandating it. thanks, Peter Thanks for the discussion, --Bruno As a result, implementations that do not send the Prefix Attribute Sub-TLV would not just be not compliant, but would also not interoperate with the ones that follow the specification. thanks, Peter If the former, could you please spell out the interop issue? Thanks, Best regards, --Bruno *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong (Geng Xuesong) *Sent:* Wednesday, May 12, 2021 9:16 AM *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde ; Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Les, Prefix Attributes sub-TLV is necessary when locator is leaked. So we are not against Prefix Attribute sub-TLV implementation. We just propose to keep it optional (“should” rather than “must”) for interoperability. Best Xuesong *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] *Sent:* Wednesday, May 12, 2021 6:29 AM *To:* Shraddha Hegde mailto:shraddha=40juniper@dmarc.ietf.org>>; Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org>; Gengxuesong (Geng Xuesong) mailto:gengxues...@huawei.com>> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> *Subject:* RE: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Shraddha/ Xuesong – Since Prefix Attributes sub-TLV is required for correct operation when a Locator is leaked, would it be safe to assume that your implementations either do not leak Locators or you advise your customers not to deploy this feature with multiple levels? The problem with allowing the sub-TLV to be optional is that if the sub-TLV is omitted you cannot tell whether the Locator has been leaked – so you don’t know whether you have a problem or not. The safest thing to do is require prefix-attributes sub-TLV always – then you can guarantee that if the prefix is leaked the necessary information will be present. Anything else leaves us vulnerable. We all appreciate interoperability considerations, but frankly this is a gap that needs to be closed to support correct operation. Les *From:*Lsr mailto:lsr-boun...@ietf.org>> *On Behalf Of *Shraddha Hegde *Sent:* Tuesday, May 11, 2021 8:21 AM *To:* Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Juniper has an implementation of SRv6 that does not support Prefix attributes sub-tlv in locator TLV. We would prefer not to change the optional sub-TLV to MUST. Rgds Shraddha Juniper Business Use Only *From:*Lsr mailto:lsr-boun...@ietf.org>> *On Behalf Of *Alvaro Retana *Sent:* Friday, May 7, 2021 7:23 PM *To:* Peter Psenak mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@iet
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Peter, Thanks for the answer. Please see inline. > From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > > On 12/05/2021 09:51, bruno.decra...@orange.com wrote: > > Hi Xuesong, > > > > Clarification question: are you talking about interoperability (between > > two nodes) or compliancy (between an implementation and the RFC)? > > I'm afraid the two are related. If we mandate the Prefix Attribute > Sub-TLV inside the Locator TLV, we would have to say that the Locator > TLV without the Prefix Attribute Sub-TLV MUST be ignored. Mandating the advertisement is one thing (if it's useful, not to mention required, let's advertise it). Then why would we have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current spec allows for both (presence & non-presence), no? That seem like an error handling situation that we can choose. Thanks for the discussion, --Bruno > As a result, > implementations that do not send the Prefix Attribute Sub-TLV would not > just be not compliant, but would also not interoperate with the ones > that follow the specification. > > thanks, > Peter > > > > > If the former, could you please spell out the interop issue? > > > > Thanks, > > > > Best regards, > > > > --Bruno > > > > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong > > (Geng Xuesong) > > *Sent:* Wednesday, May 12, 2021 9:16 AM > > *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde > > ; Alvaro Retana > > ; Peter Psenak (ppsenak) > ; > > lsr@ietf.org > > *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; > > Van De Velde, Gunter (Nokia - BE/Antwerp) > > > *Subject:* Re: [Lsr] Last Call: > > (IS-IS Extension to Support > > Segment Routing over IPv6 Dataplane) to Proposed Standard > > > > Hi Les, > > > > Prefix Attributes sub-TLV is necessary when locator is leaked. > > > > So we are not against Prefix Attribute sub-TLV implementation. We just > > propose to keep it optional (“should” rather than “must”) for > > interoperability. > > > > Best > > > > Xuesong > > > > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > > *Sent:* Wednesday, May 12, 2021 6:29 AM > > *To:* Shraddha Hegde > <mailto:shraddha=40juniper@dmarc.ietf.org>>; Alvaro Retana > > mailto:aretana.i...@gmail.com>>; Peter Psenak > > (ppsenak) mailto:ppse...@cisco.com>>; > lsr@ietf.org > > <mailto:lsr@ietf.org>; Gengxuesong (Geng Xuesong) > > mailto:gengxues...@huawei.com>> > > *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; > > draft-ietf-lsr-isis-srv6-extensi...@ietf.org > > <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, > > Gunter (Nokia - BE/Antwerp) > <mailto:gunter.van_de_ve...@nokia.com>> > > *Subject:* RE: [Lsr] Last Call: > > (IS-IS Extension to Support > > Segment Routing over IPv6 Dataplane) to Proposed Standard > > > > Shraddha/ Xuesong – > > > > Since Prefix Attributes sub-TLV is required for correct operation when a > > Locator is leaked, would it be safe to assume that your implementations > > either do not leak Locators or you advise your customers not to deploy > > this feature with multiple levels? > > > > The problem with allowing the sub-TLV to be optional is that if the > > sub-TLV is omitted you cannot tell whether the Locator has been leaked – > > so you don’t know whether you have a problem or not. > > > > The safest thing to do is require prefix-attributes sub-TLV always – > > then you can guarantee that if the prefix is leaked the necessary > > information will be present. > > > > Anything else leaves us vulnerable. > > > > We all appreciate interoperability considerations, but frankly this is a > > gap that needs to be closed to support correct operation. > > > > Les > > > > *From:*Lsr mailto:lsr-boun...@ietf.org>> *On > > Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, May 11, 2021 8:21 AM > > *To:* Alvaro Retana > <mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) > > mailto:ppse...@cisco.com>>; lsr@ietf.org > > <mailto:lsr@ietf.org> > > *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; > > draft-ietf-lsr-isis-srv6-extensi...@ietf.org > > <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, > > Gunter (Nokia - BE/Antwerp) > <mailto:gunter.van_de_ve...@nokia.
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Bruno, On 12/05/2021 09:51, bruno.decra...@orange.com wrote: Hi Xuesong, Clarification question: are you talking about interoperability (between two nodes) or compliancy (between an implementation and the RFC)? I'm afraid the two are related. If we mandate the Prefix Attribute Sub-TLV inside the Locator TLV, we would have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored. As a result, implementations that do not send the Prefix Attribute Sub-TLV would not just be not compliant, but would also not interoperate with the ones that follow the specification. thanks, Peter If the former, could you please spell out the interop issue? Thanks, Best regards, --Bruno *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong (Geng Xuesong) *Sent:* Wednesday, May 12, 2021 9:16 AM *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde ; Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Les, Prefix Attributes sub-TLV is necessary when locator is leaked. So we are not against Prefix Attribute sub-TLV implementation. We just propose to keep it optional (“should” rather than “must”) for interoperability. Best Xuesong *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] *Sent:* Wednesday, May 12, 2021 6:29 AM *To:* Shraddha Hegde <mailto:shraddha=40juniper@dmarc.ietf.org>>; Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org>; Gengxuesong (Geng Xuesong) mailto:gengxues...@huawei.com>> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) <mailto:gunter.van_de_ve...@nokia.com>> *Subject:* RE: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Shraddha/ Xuesong – Since Prefix Attributes sub-TLV is required for correct operation when a Locator is leaked, would it be safe to assume that your implementations either do not leak Locators or you advise your customers not to deploy this feature with multiple levels? The problem with allowing the sub-TLV to be optional is that if the sub-TLV is omitted you cannot tell whether the Locator has been leaked – so you don’t know whether you have a problem or not. The safest thing to do is require prefix-attributes sub-TLV always – then you can guarantee that if the prefix is leaked the necessary information will be present. Anything else leaves us vulnerable. We all appreciate interoperability considerations, but frankly this is a gap that needs to be closed to support correct operation. Les *From:*Lsr mailto:lsr-boun...@ietf.org>> *On Behalf Of *Shraddha Hegde *Sent:* Tuesday, May 11, 2021 8:21 AM *To:* Alvaro Retana <mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) <mailto:gunter.van_de_ve...@nokia.com>> *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Juniper has an implementation of SRv6 that does not support Prefix attributes sub-tlv in locator TLV. We would prefer not to change the optional sub-TLV to MUST. Rgds Shraddha Juniper Business Use Only *From:*Lsr mailto:lsr-boun...@ietf.org>> *On Behalf Of *Alvaro Retana *Sent:* Friday, May 7, 2021 7:23 PM *To:* Peter Psenak mailto:ppse...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org> *Cc:* cho...@chopps.org <mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org <mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) <mailto:gunter.van_de_ve...@nokia.com>> *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard *[External Email. Be cautious of content]* On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of n
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Xuesong,
Clarification question: are you talking about interoperability (between two
nodes) or compliancy (between an implementation and the RFC)?
If the former, could you please spell out the interop issue?
Thanks,
Best regards,
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, May 12, 2021 9:16 AM
To: Les Ginsberg (ginsberg) ; Shraddha Hegde
; Alvaro Retana
; Peter Psenak (ppsenak) ;
lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De
Velde, Gunter (Nokia - BE/Antwerp)
Subject: Re: [Lsr] Last Call:
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
Standard
Hi Les,
Prefix Attributes sub-TLV is necessary when locator is leaked.
So we are not against Prefix Attribute sub-TLV implementation. We just propose
to keep it optional ("should" rather than "must") for interoperability.
Best
Xuesong
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 12, 2021 6:29 AM
To: Shraddha Hegde
mailto:shraddha=40juniper@dmarc.ietf.org>>;
Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter
Psenak (ppsenak) mailto:ppse...@cisco.com>>;
lsr@ietf.org<mailto:lsr@ietf.org>; Gengxuesong (Geng Xuesong)
mailto:gengxues...@huawei.com>>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
Van De Velde, Gunter (Nokia - BE/Antwerp)
mailto:gunter.van_de_ve...@nokia.com>>
Subject: RE: [Lsr] Last Call:
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
Standard
Shraddha/ Xuesong -
Since Prefix Attributes sub-TLV is required for correct operation when a
Locator is leaked, would it be safe to assume that your implementations either
do not leak Locators or you advise your customers not to deploy this feature
with multiple levels?
The problem with allowing the sub-TLV to be optional is that if the sub-TLV is
omitted you cannot tell whether the Locator has been leaked - so you don't know
whether you have a problem or not.
The safest thing to do is require prefix-attributes sub-TLV always - then you
can guarantee that if the prefix is leaked the necessary information will be
present.
Anything else leaves us vulnerable.
We all appreciate interoperability considerations, but frankly this is a gap
that needs to be closed to support correct operation.
Les
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>;
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
Van De Velde, Gunter (Nokia - BE/Antwerp)
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
Standard
Juniper has an implementation of SRv6 that does not support Prefix attributes
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.
Rgds
Shraddha
Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak mailto:ppse...@cisco.com>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
Van De Velde, Gunter (Nokia - BE/Antwerp)
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
Standard
[External Email. Be cautious of content]
On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:
> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.
So...what does everyone else think?
We need to close on this point before the IESG evaluates the document. I'm
requesting it to be put on the May/20 telechat, which means that we should have
a resolution and updated draft by the end of next week.
Thanks!
Alvaro.
On May 3, 2021 at 5:17:58 AM, Peter Psenak
(ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote:
Hi Gunter,
Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Sa
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Les,
Prefix Attributes sub-TLV is necessary when locator is leaked.
So we are not against Prefix Attribute sub-TLV implementation. We just propose
to keep it optional ("should" rather than "must") for interoperability.
Best
Xuesong
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 12, 2021 6:29 AM
To: Shraddha Hegde ; Alvaro Retana
; Peter Psenak (ppsenak) ;
lsr@ietf.org; Gengxuesong (Geng Xuesong)
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De
Velde, Gunter (Nokia - BE/Antwerp)
Subject: RE: [Lsr] Last Call:
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
Standard
Shraddha/ Xuesong -
Since Prefix Attributes sub-TLV is required for correct operation when a
Locator is leaked, would it be safe to assume that your implementations either
do not leak Locators or you advise your customers not to deploy this feature
with multiple levels?
The problem with allowing the sub-TLV to be optional is that if the sub-TLV is
omitted you cannot tell whether the Locator has been leaked - so you don't know
whether you have a problem or not.
The safest thing to do is require prefix-attributes sub-TLV always - then you
can guarantee that if the prefix is leaked the necessary information will be
present.
Anything else leaves us vulnerable.
We all appreciate interoperability considerations, but frankly this is a gap
that needs to be closed to support correct operation.
Les
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>;
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
Van De Velde, Gunter (Nokia - BE/Antwerp)
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
Standard
Juniper has an implementation of SRv6 that does not support Prefix attributes
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.
Rgds
Shraddha
Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak mailto:ppse...@cisco.com>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
Van De Velde, Gunter (Nokia - BE/Antwerp)
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
Standard
[External Email. Be cautious of content]
On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:
> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.
So...what does everyone else think?
We need to close on this point before the IESG evaluates the document. I'm
requesting it to be put on the May/20 telechat, which means that we should have
a resolution and updated draft by the end of next week.
Thanks!
Alvaro.
On May 3, 2021 at 5:17:58 AM, Peter Psenak
(ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote:
Hi Gunter,
Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.
SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.
Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.
thanks,
Peter
On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the
> prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator has
> been redistributed or not for a correct operation.
>
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2 to L1.
> ** So this end-sid will not be used as we know that it is redistrib
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Shraddha/ Xuesong - Since Prefix Attributes sub-TLV is required for correct operation when a Locator is leaked, would it be safe to assume that your implementations either do not leak Locators or you advise your customers not to deploy this feature with multiple levels? The problem with allowing the sub-TLV to be optional is that if the sub-TLV is omitted you cannot tell whether the Locator has been leaked - so you don't know whether you have a problem or not. The safest thing to do is require prefix-attributes sub-TLV always - then you can guarantee that if the prefix is leaked the necessary information will be present. Anything else leaves us vulnerable. We all appreciate interoperability considerations, but frankly this is a gap that needs to be closed to support correct operation. Les From: Lsr On Behalf Of Shraddha Hegde Sent: Tuesday, May 11, 2021 8:21 AM To: Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Juniper has an implementation of SRv6 that does not support Prefix attributes sub-tlv in locator TLV. We would prefer not to change the optional sub-TLV to MUST. Rgds Shraddha Juniper Business Use Only From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Alvaro Retana Sent: Friday, May 7, 2021 7:23 PM To: Peter Psenak mailto:ppse...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard [External Email. Be cautious of content] On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the > prefix-attribute tlv is mandatory when a locator is redistributed? > > Why? > *When calculating a LFA for an SRv6 End.SID we better know if the locator has > been redistributed or not for a correct operation. > > Reasoning: > * A locator has the D bit. This one is set when we redistribute from L2 to L1. > ** So this end-sid will not be used as we know that it is redistributed. > > * In the other direction (L1-L2), we only know that a locator is > redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised. > ** This means if the operator does not configure advertisement of the > prefix-attribute tlv, ISIS could potentially use an end-sid which does not > terminate on the expected node. > > * Compared to sr-mpls, a prefix-sid has the R flag indicating it is > redistributed. > * We don't have that for locator end-sids. > > Relevant snip from " draft-ietf-lsr-isis-srv6-extensions" > > 7.1. SRv6 Locator TLV Format > > The SRv6 Locator TLV has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |R|R|R|R| MT ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > T
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Juniper has an implementation of SRv6 that does not support Prefix attributes sub-tlv in locator TLV. We would prefer not to change the optional sub-TLV to MUST. Rgds Shraddha Juniper Business Use Only From: Lsr On Behalf Of Alvaro Retana Sent: Friday, May 7, 2021 7:23 PM To: Peter Psenak ; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard [External Email. Be cautious of content] On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the > prefix-attribute tlv is mandatory when a locator is redistributed? > > Why? > *When calculating a LFA for an SRv6 End.SID we better know if the locator has > been redistributed or not for a correct operation. > > Reasoning: > * A locator has the D bit. This one is set when we redistribute from L2 to L1. > ** So this end-sid will not be used as we know that it is redistributed. > > * In the other direction (L1-L2), we only know that a locator is > redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised. > ** This means if the operator does not configure advertisement of the > prefix-attribute tlv, ISIS could potentially use an end-sid which does not > terminate on the expected node. > > * Compared to sr-mpls, a prefix-sid has the R flag indicating it is > redistributed. > * We don't have that for locator end-sids. > > Relevant snip from " draft-ietf-lsr-isis-srv6-extensions" > > 7.1. SRv6 Locator TLV Format > > The SRv6 Locator TLV has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |R|R|R|R| MT ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 27 > > Length: variable. > > R bits: reserved for future use. They MUST be > set to zero on transmission and MUST be ignored on receipt. > > MT ID: Multitopology Identifier as defined in [RFC5120]. > Note that the value 0 is legal. > > Followed by one or more locator entries of the form: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Algorithm | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Loc Size | Locator (variable)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-TLV-len | Sub-TLVs (variable) . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Metric: 4 octets. As described in [RFC5305]. > > Flags: 1 octet. The following flags are defined > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |D| Reserved | > +-+-+-+-+-+-+-+-+ > > where: > D-flag: Same as described in section 4.1. of [RFC5305]. > > > G/ > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Les, Thanks for mentioning the compatibility issue. The prefix-attributes sub-TLV is not supported in the existing implementation of SRv6 ISIS in Huawei device. So maybe we should be more cautious before deciding to change it from optional to mandatory. Best Xuesong From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Saturday, May 8, 2021 12:52 AM To: Ketan Talaulikar (ketant) ; Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard As has been mentioned in this thread, the need for the prefix-attributes sub-TLV to correctly process leaked advertisements is not unique to the Locator TLV. The reason prefix-attributes TLV was created was to address the same gap with IP/IPv6 reachability advertisements. And I think by now implementations (certainly ones that support newer functionality like SRv6) should have added support for prefix-attributes sub-TLV . In the case of the Locator TLV – since this is new functionality – we have the option of mandating prefix-attributes sub-TLV – something we could not do with IP/IPv6 Reachability since that has been deployed for many years. But, please recognize two consequences of the MUST option: 1)Implementations may have to deal w backwards compatibility w early deployments of SRv6. This would only be an issue if there are implementations that currently do NOT send prefix-attributes sub-TLV w Locator TLV. Are there any such implementations?? 2)In the case where the deployment is a single level, it could be argued that prefix-attributes sub-TLV isn’t needed. I personally would NOT make such an argument, but we should understand that MUST applies to this case as well. If everyone is OK with these consequences (personally I am OK) then I think it is fine to go with MUST. Les From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Ketan Talaulikar (ketant) Sent: Friday, May 07, 2021 7:00 AM To: Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Peter, I agree that the support for the Prefix Attribute Flags TLV is required in the Locator TLV. Thanks, Ketan From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Alvaro Retana Sent: 07 May 2021 19:23 To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the > p
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
+1 Cheers, Jeff On May 7, 2021, 9:53 AM -0700, Les Ginsberg (ginsberg) , wrote: > As has been mentioned in this thread, the need for the prefix-attributes > sub-TLV to correctly process leaked advertisements is not unique to the > Locator TLV. The reason prefix-attributes TLV was created was to address the > same gap with IP/IPv6 reachability advertisements. > And I think by now implementations (certainly ones that support newer > functionality like SRv6) should have added support for prefix-attributes > sub-TLV . > > In the case of the Locator TLV – since this is new functionality – we have > the option of mandating prefix-attributes sub-TLV – something we could not do > with IP/IPv6 Reachability since that has been deployed for many years. > > But, please recognize two consequences of the MUST option: > > 1)Implementations may have to deal w backwards compatibility w early > deployments of SRv6. This would only be an issue if there are implementations > that currently do NOT send prefix-attributes sub-TLV w Locator TLV. > Are there any such implementations?? > > 2)In the case where the deployment is a single level, it could be argued that > prefix-attributes sub-TLV isn’t needed. > I personally would NOT make such an argument, but we should understand that > MUST applies to this case as well. > > If everyone is OK with these consequences (personally I am OK) then I think > it is fine to go with MUST. > > Les > > > From: Lsr On Behalf Of Ketan Talaulikar (ketant) > Sent: Friday, May 07, 2021 7:00 AM > To: Alvaro Retana ; Peter Psenak (ppsenak) > ; lsr@ietf.org > Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De > Velde, Gunter (Nokia - BE/Antwerp) > Subject: Re: [Lsr] Last Call: > (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed > Standard > > Hi Peter, > > I agree that the support for the Prefix Attribute Flags TLV is required in > the Locator TLV. > > Thanks, > Ketan > > From: Lsr On Behalf Of Alvaro Retana > Sent: 07 May 2021 19:23 > To: Peter Psenak (ppsenak) ; lsr@ietf.org > Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De > Velde, Gunter (Nokia - BE/Antwerp) > Subject: Re: [Lsr] Last Call: > (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed > Standard > > On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > > > Technically I agree with you and if everybody agrees, I'm fine to > > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. > > So...what does everyone else think? > > We need to close on this point before the IESG evaluates the document. I'm > requesting it to be put on the May/20 telechat, which means that we should > have a resolution and updated draft by the end of next week. > > > Thanks! > > Alvaro. > > > On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com) wrote: > > Hi Gunter, > > > > Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. > > The problem you describe is not specific to Locator TLV, same applies to > > regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix > > Attribute Flags TLV is not included, one can not tell whether the prefix > > has been propagated (L1->L2) or generated as a result of the local > > interface attached on the originator. Same applies to redistribution and > > R-flag for IPv4 prefix TLVs. > > > > SRv6 Locator TLV has been defined a while back and the Prefix Attribute > > Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we > > can start to mandate the Prefix Attribute Flags TLV at this point. > > > > Technically I agree with you and if everybody agrees, I'm fine to > > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. > > > > thanks, > > Peter > > > > > > On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > > > Hi Peter, All, > > > > > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the > > > prefix-attribute tlv is mandatory when a locator is redistributed? > > > > > > Why? > > > *When calculating a LFA for an SRv6 End.SID we better know if the locator > > > has been redistributed or not for a correct operation. > > > > > > Reasoning: > > > * A locator has the D bit. This one is set when we redistribute from L2 > > > to L1. > > > ** So this end-sid will not be used as we know that it is redistributed. > > > > > > * In the other direct
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Speaking as WG contributor: From: Lsr on behalf of "Les Ginsberg (ginsberg)" Date: Friday, May 7, 2021 at 12:53 PM To: "Ketan Talaulikar (ketant)" , Alvaro Retana , "Peter Psenak (ppsenak)" , "lsr@ietf.org" Cc: Christian Hopps , "draft-ietf-lsr-isis-srv6-extensi...@ietf.org" , Gunter Van de Velde Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard As has been mentioned in this thread, the need for the prefix-attributes sub-TLV to correctly process leaked advertisements is not unique to the Locator TLV. The reason prefix-attributes TLV was created was to address the same gap with IP/IPv6 reachability advertisements. And I think by now implementations (certainly ones that support newer functionality like SRv6) should have added support for prefix-attributes sub-TLV . In the case of the Locator TLV – since this is new functionality – we have the option of mandating prefix-attributes sub-TLV – something we could not do with IP/IPv6 Reachability since that has been deployed for many years. But, please recognize two consequences of the MUST option: 1)Implementations may have to deal w backwards compatibility w early deployments of SRv6. This would only be an issue if there are implementations that currently do NOT send prefix-attributes sub-TLV w Locator TLV. Are there any such implementations?? 2)In the case where the deployment is a single level, it could be argued that prefix-attributes sub-TLV isn’t needed. I personally would NOT make such an argument, but we should understand that MUST applies to this case as well. If everyone is OK with these consequences (personally I am OK) then I think it is fine to go with MUST. I’m fine with these consequences. Better to fix this now and not use the SRv6 Prefix non-deterministically. Thanks, Acee Les From: Lsr On Behalf Of Ketan Talaulikar (ketant) Sent: Friday, May 07, 2021 7:00 AM To: Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Peter, I agree that the support for the Prefix Attribute Flags TLV is required in the Locator TLV. Thanks, Ketan From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Alvaro Retana Sent: 07 May 2021 19:23 To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the > prefix-attribute tlv is mandatory when a locator is redistributed? > > Why? > *When calculating a LFA for an SRv6 End.SID we better know if the locator has > been redistributed or not for a correct operation. > > Reasoning: > * A locator has the D bit. This one is set when we redistribute from L2 to L1. > ** So this end-sid will not be used as w
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
As has been mentioned in this thread, the need for the prefix-attributes sub-TLV to correctly process leaked advertisements is not unique to the Locator TLV. The reason prefix-attributes TLV was created was to address the same gap with IP/IPv6 reachability advertisements. And I think by now implementations (certainly ones that support newer functionality like SRv6) should have added support for prefix-attributes sub-TLV . In the case of the Locator TLV – since this is new functionality – we have the option of mandating prefix-attributes sub-TLV – something we could not do with IP/IPv6 Reachability since that has been deployed for many years. But, please recognize two consequences of the MUST option: 1)Implementations may have to deal w backwards compatibility w early deployments of SRv6. This would only be an issue if there are implementations that currently do NOT send prefix-attributes sub-TLV w Locator TLV. Are there any such implementations?? 2)In the case where the deployment is a single level, it could be argued that prefix-attributes sub-TLV isn’t needed. I personally would NOT make such an argument, but we should understand that MUST applies to this case as well. If everyone is OK with these consequences (personally I am OK) then I think it is fine to go with MUST. Les From: Lsr On Behalf Of Ketan Talaulikar (ketant) Sent: Friday, May 07, 2021 7:00 AM To: Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Peter, I agree that the support for the Prefix Attribute Flags TLV is required in the Locator TLV. Thanks, Ketan From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Alvaro Retana Sent: 07 May 2021 19:23 To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org>; draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the > prefix-attribute tlv is mandatory when a locator is redistributed? > > Why? > *When calculating a LFA for an SRv6 End.SID we better know if the locator has > been redistributed or not for a correct operation. > > Reasoning: > * A locator has the D bit. This one is set when we redistribute from L2 to L1. > ** So this end-sid will not be used as we know that it is redistributed. > > * In the other direction (L1-L2), we only know that a locator is > redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised. > ** This means if the operator does not configure advertisement of the > prefix-attribute tlv, ISIS could potentially use an end-sid which does not > terminate on the expected node. > > * Compared to sr-mpls, a prefix-sid has the R flag indicating it is > redistributed. > * We don't have that for locator end-sids. > > Relevant snip from " draft-ietf-lsr-isis-srv6-extensions
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Peter, I agree that the support for the Prefix Attribute Flags TLV is required in the Locator TLV. Thanks, Ketan From: Lsr On Behalf Of Alvaro Retana Sent: 07 May 2021 19:23 To: Peter Psenak (ppsenak) ; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the > prefix-attribute tlv is mandatory when a locator is redistributed? > > Why? > *When calculating a LFA for an SRv6 End.SID we better know if the locator has > been redistributed or not for a correct operation. > > Reasoning: > * A locator has the D bit. This one is set when we redistribute from L2 to L1. > ** So this end-sid will not be used as we know that it is redistributed. > > * In the other direction (L1-L2), we only know that a locator is > redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised. > ** This means if the operator does not configure advertisement of the > prefix-attribute tlv, ISIS could potentially use an end-sid which does not > terminate on the expected node. > > * Compared to sr-mpls, a prefix-sid has the R flag indicating it is > redistributed. > * We don't have that for locator end-sids. > > Relevant snip from " draft-ietf-lsr-isis-srv6-extensions" > > 7.1. SRv6 Locator TLV Format > > The SRv6 Locator TLV has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |R|R|R|R| MT ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 27 > > Length: variable. > > R bits: reserved for future use. They MUST be > set to zero on transmission and MUST be ignored on receipt. > > MT ID: Multitopology Identifier as defined in [RFC5120]. > Note that the value 0 is legal. > > Followed by one or more locator entries of the form: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Algorithm | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Loc Size | Locator (variable)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-TLV-len | Sub-TLVs (variable) . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Metric: 4 octets. As described in [RFC5305]. > > Flags: 1 octet. The following flags are defined > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |D| Reserved | > +-+-+-+-+-+-+-+-+ > > where: > D-flag: Same as described in section 4.1. of [RFC5305]. > > > G/ > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the document. I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week. Thanks! Alvaro. On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com) wrote: Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the prefix-attribute tlv is mandatory when a locator is redistributed? > > Why? > *When calculating a LFA for an SRv6 End.SID we better know if the locator has been redistributed or not for a correct operation. > > Reasoning: > * A locator has the D bit. This one is set when we redistribute from L2 to L1. > ** So this end-sid will not be used as we know that it is redistributed. > > * In the other direction (L1-L2), we only know that a locator is redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised. > ** This means if the operator does not configure advertisement of the prefix-attribute tlv, ISIS could potentially use an end-sid which does not terminate on the expected node. > > * Compared to sr-mpls, a prefix-sid has the R flag indicating it is redistributed. > * We don't have that for locator end-sids. > > Relevant snip from " draft-ietf-lsr-isis-srv6-extensions" > > 7.1. SRv6 Locator TLV Format > > The SRv6 Locator TLV has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |R|R|R|R| MT ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 27 > > Length: variable. > > R bits: reserved for future use. They MUST be > set to zero on transmission and MUST be ignored on receipt. > > MT ID: Multitopology Identifier as defined in [RFC5120]. > Note that the value 0 is legal. > > Followed by one or more locator entries of the form: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Algorithm | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Loc Size | Locator (variable)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-TLV-len | Sub-TLVs (variable) . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Metric: 4 octets. As described in [RFC5305]. > > Flags: 1 octet. The following flags are defined > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |D| Reserved | > +-+-+-+-+-+-+-+-+ > > where: > D-flag: Same as described in section 4.1. of [RFC5305]. > > > G/ > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Gunter, Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. The problem you describe is not specific to Locator TLV, same applies to regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix Attribute Flags TLV is not included, one can not tell whether the prefix has been propagated (L1->L2) or generated as a result of the local interface attached on the originator. Same applies to redistribution and R-flag for IPv4 prefix TLVs. SRv6 Locator TLV has been defined a while back and the Prefix Attribute Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we can start to mandate the Prefix Attribute Flags TLV at this point. Technically I agree with you and if everybody agrees, I'm fine to enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. thanks, Peter On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: Hi Peter, All, Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the prefix-attribute tlv is mandatory when a locator is redistributed? Why? *When calculating a LFA for an SRv6 End.SID we better know if the locator has been redistributed or not for a correct operation. Reasoning: * A locator has the D bit. This one is set when we redistribute from L2 to L1. ** So this end-sid will not be used as we know that it is redistributed. * In the other direction (L1-L2), we only know that a locator is redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised. ** This means if the operator does not configure advertisement of the prefix-attribute tlv, ISIS could potentially use an end-sid which does not terminate on the expected node. * Compared to sr-mpls, a prefix-sid has the R flag indicating it is redistributed. * We don't have that for locator end-sids. Relevant snip from " draft-ietf-lsr-isis-srv6-extensions" 7.1. SRv6 Locator TLV Format The SRv6 Locator TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type| Length|R|R|R|R|MT ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 27 Length: variable. R bits: reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. MT ID: Multitopology Identifier as defined in [RFC5120]. Note that the value 0 is legal. Followed by one or more locator entries of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loc Size | Locator (variable)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV-len | Sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Metric: 4 octets. As described in [RFC5305]. Flags: 1 octet. The following flags are defined 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D|Reserved | +-+-+-+-+-+-+-+-+ where: D-flag: Same as described in section 4.1. of [RFC5305]. G/ -Original Message- From: Lsr On Behalf Of The IESG Sent: Thursday, April 22, 2021 10:14 PM To: IETF-Announce Cc: lsr@ietf.org; lsr-cha...@ietf.org; cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; aretana.i...@gmail.com Subject: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extension to Support Segment Routing over IPv6 Dataplane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-05-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Segment Routing (SR) allows for a flexible definition of end-to- end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Th
Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Hi Peter, All, Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the prefix-attribute tlv is mandatory when a locator is redistributed? Why? *When calculating a LFA for an SRv6 End.SID we better know if the locator has been redistributed or not for a correct operation. Reasoning: * A locator has the D bit. This one is set when we redistribute from L2 to L1. ** So this end-sid will not be used as we know that it is redistributed. * In the other direction (L1-L2), we only know that a locator is redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised. ** This means if the operator does not configure advertisement of the prefix-attribute tlv, ISIS could potentially use an end-sid which does not terminate on the expected node. * Compared to sr-mpls, a prefix-sid has the R flag indicating it is redistributed. * We don't have that for locator end-sids. Relevant snip from " draft-ietf-lsr-isis-srv6-extensions" 7.1. SRv6 Locator TLV Format The SRv6 Locator TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type| Length|R|R|R|R|MT ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 27 Length: variable. R bits: reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. MT ID: Multitopology Identifier as defined in [RFC5120]. Note that the value 0 is legal. Followed by one or more locator entries of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loc Size | Locator (variable)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV-len | Sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Metric: 4 octets. As described in [RFC5305]. Flags: 1 octet. The following flags are defined 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D|Reserved | +-+-+-+-+-+-+-+-+ where: D-flag: Same as described in section 4.1. of [RFC5305]. G/ -Original Message- From: Lsr On Behalf Of The IESG Sent: Thursday, April 22, 2021 10:14 PM To: IETF-Announce Cc: lsr@ietf.org; lsr-cha...@ietf.org; cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; aretana.i...@gmail.com Subject: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extension to Support Segment Routing over IPv6 Dataplane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-05-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Segment Routing (SR) allows for a flexible definition of end-to- end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This document describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. This documents updates RFC 7370 by modifying an existing registry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3796/ https://datatracker.ietf.org/ipr/4486/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extension to Support Segment Routing over IPv6 Dataplane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-05-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Segment Routing (SR) allows for a flexible definition of end-to- end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This document describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. This documents updates RFC 7370 by modifying an existing registry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3796/ https://datatracker.ietf.org/ipr/4486/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
