Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hi Peter, You're correct w.r.t. E-Intra-Area-Prefix-LSA It's different for E-Inter-Area-Prefix-LSA. As mentioned, rfc8362 explicitly says below: "If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, it is treated as malformed as described in Section 5." So an E-Inter-Area-Prefix-LSA without an E-Inter-Area-Prefix-LSA is considered malformed and rejected by our implementation. As a result, our implementation always add an Inter-Area-Prefix TLV when advertising a "OSPFv3 Extended Prefix Range TLV" in a E-Inter-Area-Prefix-LSA. The Inter-Area-Prefix TLV is filled with all zero's, and the NU-bit is set so that it gets ignored. Maybe, we can do same for this SRv6 locator. Regards, Dirk -Original Message- From: Peter Psenak Sent: Tuesday, September 14, 2021 11:52 AM To: Ketan Talaulikar (ketant) ; Goethals, Dirk (Nokia - BE/Antwerp) ; lsr@ietf.org Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, On 14/09/2021 11:24, Ketan Talaulikar (ketant) wrote: > Hi Dirk, > > Your point is related to my original concern/interpretation for why we > introduced a new LSA type for SRv6 Locator than use the existing > Extended Prefix LSA types. This goes back to the original intention of > the WG and authors of RFC8362. > > If one can never generate the E-*-Prefix LSAs (e.g. > E-Inter-Area-Prefix-LSA) without the presence/inclusion of their > corresponding “base” prefix-reachability TLVs (e.g. Inter-Area-Prefix > TLV), then these extended LSAs cannot be used for advertisement of > SRv6 Locators in OSPFv3. This is because, for FlexAlgo we need the > ability to advertise only the SRv6 Locators without the “base” prefix > reachability. > > I was made to understand, however, that the text in RFC8362 was only > in the context of base OSPFv3 SPF and it was not intended to make the > “base” prefix reachability TLVs mandatory in the extended LSAs. Hence > the proposal for this change. > > Would like to know the WG and RFC8362 authors views on this aspect. > > Regd the NU bit, that applies for when Prefix SID mapping for an > individual prefix is advertised by the SRMS by using the Prefix-SID > sub-TLV inside the Intra/Inter/External Prefix TLVs. I was talking > about the advertisement of ranges using the OSPFv3 Extended Prefix > Range TLVs – there is no NU bit in the picture here AFAIK. I am > referring to the text in > https://datatracker.ietf.org/doc/html/rfc8666#section-8.1 > > Are you saying that implementations today are advertising say > Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended > Prefix Range TLV in the same E-Intra-Area-Prefix LSA for advertisement > of SRMS ranges? If so, this was not very clear to me from RFC8666. I see no reason to send Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended Prefix Range TLV. The text in rfc8666 says "An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs when advertising SIDs for prefixes.". That should be sufficient. thanks, Peter > > Thanks, > > Ketan > > *From:*Goethals, Dirk (Nokia - BE/Antwerp) > *Sent:* 14 September 2021 14:15 > *To:* Ketan Talaulikar (ketant) ; Ketan Talaulikar > (ketant) ; lsr@ietf.org > *Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding > > Hi Ketan, > > I’m not sure I understand your reply correctly. > > The same paragraph also mentions: > > If the Inter-Area-Prefix TLV is not included in the > E-Inter-Area-Prefix-LSA, > > it is treated as malformed as described in Section 5 > <https://datatracker.ietf.org/doc/html/rfc8362#section-5>. > > w.r.t OSPFv3 Extended Prefix Range TLV > > I’ve been told that the NU-bit > (https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1) > > is used to exclude it from unicast. > > I’m I missing something? > > Thx, > > Dirk > > *From:*Ketan Talaulikar (ketant) <mailto:ket...@cisco.com>> > *Sent:* Tuesday, September 14, 2021 9:56 AM > *To:* Goethals, Dirk (Nokia - BE/Antwerp) <mailto:dirk.goeth...@nokia.com>>; Ketan Talaulikar (ketant) > <mailto:ketant=40cisco@dmarc.ietf.org>>; lsr@ietf.org > <mailto:lsr@ietf.org> > *Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding > > Hi Dirk, > > There was a misunderstanding of Acee's comment and its context on my > part. More specifically my misunderstanding on what RFC8362 text > intended to say. > > E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says > the following > > In order to retain > > compatibility and semantics with the current OSPFv3 specification, > > each Inter-Area-Prefix LSA MUST cont
Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hi Ketan, On 14/09/2021 11:24, Ketan Talaulikar (ketant) wrote: Hi Dirk, Your point is related to my original concern/interpretation for why we introduced a new LSA type for SRv6 Locator than use the existing Extended Prefix LSA types. This goes back to the original intention of the WG and authors of RFC8362. If one can never generate the E-*-Prefix LSAs (e.g. E-Inter-Area-Prefix-LSA) without the presence/inclusion of their corresponding “base” prefix-reachability TLVs (e.g. Inter-Area-Prefix TLV), then these extended LSAs cannot be used for advertisement of SRv6 Locators in OSPFv3. This is because, for FlexAlgo we need the ability to advertise only the SRv6 Locators without the “base” prefix reachability. I was made to understand, however, that the text in RFC8362 was only in the context of base OSPFv3 SPF and it was not intended to make the “base” prefix reachability TLVs mandatory in the extended LSAs. Hence the proposal for this change. Would like to know the WG and RFC8362 authors views on this aspect. Regd the NU bit, that applies for when Prefix SID mapping for an individual prefix is advertised by the SRMS by using the Prefix-SID sub-TLV inside the Intra/Inter/External Prefix TLVs. I was talking about the advertisement of ranges using the OSPFv3 Extended Prefix Range TLVs – there is no NU bit in the picture here AFAIK. I am referring to the text in https://datatracker.ietf.org/doc/html/rfc8666#section-8.1 Are you saying that implementations today are advertising say Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended Prefix Range TLV in the same E-Intra-Area-Prefix LSA for advertisement of SRMS ranges? If so, this was not very clear to me from RFC8666. I see no reason to send Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended Prefix Range TLV. The text in rfc8666 says "An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs when advertising SIDs for prefixes.". That should be sufficient. thanks, Peter Thanks, Ketan *From:*Goethals, Dirk (Nokia - BE/Antwerp) *Sent:* 14 September 2021 14:15 *To:* Ketan Talaulikar (ketant) ; Ketan Talaulikar (ketant) ; lsr@ietf.org *Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, I’m not sure I understand your reply correctly. The same paragraph also mentions: If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, it is treated as malformed as described in Section 5 <https://datatracker.ietf.org/doc/html/rfc8362#section-5>. w.r.t OSPFv3 Extended Prefix Range TLV I’ve been told that the NU-bit (https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1) is used to exclude it from unicast. I’m I missing something? Thx, Dirk *From:*Ketan Talaulikar (ketant) <mailto:ket...@cisco.com>> *Sent:* Tuesday, September 14, 2021 9:56 AM *To:* Goethals, Dirk (Nokia - BE/Antwerp) <mailto:dirk.goeth...@nokia.com>>; Ketan Talaulikar (ketant) <mailto:ketant=40cisco@dmarc.ietf.org>>; lsr@ietf.org <mailto:lsr@ietf.org> *Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding Hi Dirk, There was a misunderstanding of Acee's comment and its context on my part. More specifically my misunderstanding on what RFC8362 text intended to say. E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says the following In order to retain compatibility and semantics with the current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix TLV. I read this as Inter-Area-Prefix TLV must be present in an OSPFv3 E-Inter-Area-Prefix LSA and other TLVs may be added optionally. However, this does not seem to be the correct interpretation since we already have introduced the OSPFv3 Extended Prefix Range TLV in https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a top-level TLV and may be used for a prefix without its corresponding Inter-Area-Prefix TLV. So we can introduce the SRv6 Locator TLV similar to the Prefix Range TLV into the existing Prefix LSAs as indicated by Acee and there would not be an issue. Thanks, Ketan -Original Message- From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp) Sent: 14 September 2021 12:58 To: Ketan Talaulikar (ketant) <mailto:ketant=40cisco@dmarc.ietf.org>>; lsr@ietf.org <mailto:lsr@ietf.org> Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, I'm not against this suggested change. I noticed however, that Acee suggested this a while back and at that time you mentioned an issue when flex-algo locators where advertised this way, see snip below. Can you elaborate on why this is no longer an issue? Thx, Dirk [Acee] Why do you define a separate SRv6 Locator LSA to advertise SRv6 reachability? One of the primary benefits of RFC8362 is to advertise all the inform
Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hi Dirk, Your point is related to my original concern/interpretation for why we introduced a new LSA type for SRv6 Locator than use the existing Extended Prefix LSA types. This goes back to the original intention of the WG and authors of RFC8362. If one can never generate the E-*-Prefix LSAs (e.g. E-Inter-Area-Prefix-LSA) without the presence/inclusion of their corresponding "base" prefix-reachability TLVs (e.g. Inter-Area-Prefix TLV), then these extended LSAs cannot be used for advertisement of SRv6 Locators in OSPFv3. This is because, for FlexAlgo we need the ability to advertise only the SRv6 Locators without the "base" prefix reachability. I was made to understand, however, that the text in RFC8362 was only in the context of base OSPFv3 SPF and it was not intended to make the "base" prefix reachability TLVs mandatory in the extended LSAs. Hence the proposal for this change. Would like to know the WG and RFC8362 authors views on this aspect. Regd the NU bit, that applies for when Prefix SID mapping for an individual prefix is advertised by the SRMS by using the Prefix-SID sub-TLV inside the Intra/Inter/External Prefix TLVs. I was talking about the advertisement of ranges using the OSPFv3 Extended Prefix Range TLVs - there is no NU bit in the picture here AFAIK. I am referring to the text in https://datatracker.ietf.org/doc/html/rfc8666#section-8.1 Are you saying that implementations today are advertising say Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended Prefix Range TLV in the same E-Intra-Area-Prefix LSA for advertisement of SRMS ranges? If so, this was not very clear to me from RFC8666. Thanks, Ketan From: Goethals, Dirk (Nokia - BE/Antwerp) Sent: 14 September 2021 14:15 To: Ketan Talaulikar (ketant) ; Ketan Talaulikar (ketant) ; lsr@ietf.org Subject: RE: Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, I'm not sure I understand your reply correctly. The same paragraph also mentions: If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, it is treated as malformed as described in Section 5<https://datatracker.ietf.org/doc/html/rfc8362#section-5>. w.r.t OSPFv3 Extended Prefix Range TLV I've been told that the NU-bit (https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1) is used to exclude it from unicast. I'm I missing something? Thx, Dirk From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>> Sent: Tuesday, September 14, 2021 9:56 AM To: Goethals, Dirk (Nokia - BE/Antwerp) mailto:dirk.goeth...@nokia.com>>; Ketan Talaulikar (ketant) mailto:ketant=40cisco@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Proposed changes for OSPFv3 SRv6 encoding Hi Dirk, There was a misunderstanding of Acee's comment and its context on my part. More specifically my misunderstanding on what RFC8362 text intended to say. E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says the following In order to retain compatibility and semantics with the current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix TLV. I read this as Inter-Area-Prefix TLV must be present in an OSPFv3 E-Inter-Area-Prefix LSA and other TLVs may be added optionally. However, this does not seem to be the correct interpretation since we already have introduced the OSPFv3 Extended Prefix Range TLV in https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a top-level TLV and may be used for a prefix without its corresponding Inter-Area-Prefix TLV. So we can introduce the SRv6 Locator TLV similar to the Prefix Range TLV into the existing Prefix LSAs as indicated by Acee and there would not be an issue. Thanks, Ketan -Original Message- From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp) Sent: 14 September 2021 12:58 To: Ketan Talaulikar (ketant) mailto:ketant=40cisco@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, I'm not against this suggested change. I noticed however, that Acee suggested this a while back and at that time you mentioned an issue when flex-algo locators where advertised this way, see snip below. Can you elaborate on why this is no longer an issue? Thx, Dirk [Acee] Why do you define a separate SRv6 Locator LSA to advertise SRv6 reachability? One of the primary benefits of RFC8362 is to advertise all the information associated with a prefix in one LSA. Now you have negated that benefit by putting this information in a separate LSA. [KT] We need to define a new LSA since this is not an extension for the normal prefix reachability. For doing FlexAlgo with SRv6, the locators are used for reachability computation within the FlexAlgo. If these were advertised as normal prefix
Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hi Ketan, I'm not sure I understand your reply correctly. The same paragraph also mentions: If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, it is treated as malformed as described in Section 5<https://datatracker.ietf.org/doc/html/rfc8362#section-5>. w.r.t OSPFv3 Extended Prefix Range TLV I've been told that the NU-bit (https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1) is used to exclude it from unicast. I'm I missing something? Thx, Dirk From: Ketan Talaulikar (ketant) Sent: Tuesday, September 14, 2021 9:56 AM To: Goethals, Dirk (Nokia - BE/Antwerp) ; Ketan Talaulikar (ketant) ; lsr@ietf.org Subject: RE: Proposed changes for OSPFv3 SRv6 encoding Hi Dirk, There was a misunderstanding of Acee's comment and its context on my part. More specifically my misunderstanding on what RFC8362 text intended to say. E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says the following In order to retain compatibility and semantics with the current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix TLV. I read this as Inter-Area-Prefix TLV must be present in an OSPFv3 E-Inter-Area-Prefix LSA and other TLVs may be added optionally. However, this does not seem to be the correct interpretation since we already have introduced the OSPFv3 Extended Prefix Range TLV in https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a top-level TLV and may be used for a prefix without its corresponding Inter-Area-Prefix TLV. So we can introduce the SRv6 Locator TLV similar to the Prefix Range TLV into the existing Prefix LSAs as indicated by Acee and there would not be an issue. Thanks, Ketan -Original Message- From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp) Sent: 14 September 2021 12:58 To: Ketan Talaulikar (ketant) mailto:ketant=40cisco@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, I'm not against this suggested change. I noticed however, that Acee suggested this a while back and at that time you mentioned an issue when flex-algo locators where advertised this way, see snip below. Can you elaborate on why this is no longer an issue? Thx, Dirk [Acee] Why do you define a separate SRv6 Locator LSA to advertise SRv6 reachability? One of the primary benefits of RFC8362 is to advertise all the information associated with a prefix in one LSA. Now you have negated that benefit by putting this information in a separate LSA. [KT] We need to define a new LSA since this is not an extension for the normal prefix reachability. For doing FlexAlgo with SRv6, the locators are used for reachability computation within the FlexAlgo. If these were advertised as normal prefix reachability then routers which are not part of the FlexAlgo or even routers not supporting SRv6 would program them. We've tried to explain this in https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5. -Original Message- From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Ketan Talaulikar (ketant) Sent: Monday, September 13, 2021 6:29 PM To: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hello All, Some feedback has been received with suggestions to change the encoding currently proposed in the draft - more specifically related to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-02#section-6 The proposal is to do away with the need for introduction of a new LSA for SRv6 Locator and instead advertise the SRv6 Locator as a new top-level TLV within all the extended Prefix LSAs introduced in RFC8362. The advantage is simpler processing for the scenarios where the prefix is advertised as both a normal prefix reachability as well as SRv6 Locator. It also results in avoiding the handling of a new LSA type in OSPFv3. I would like to poll the WG to check if there are any existing implementations of the draft in the current form (even though codepoints have not yet been allocated). Also, if there is any objection to introducing this change. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hi Dirk, There was a misunderstanding of Acee's comment and its context on my part. More specifically my misunderstanding on what RFC8362 text intended to say. E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says the following In order to retain compatibility and semantics with the current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix TLV. I read this as Inter-Area-Prefix TLV must be present in an OSPFv3 E-Inter-Area-Prefix LSA and other TLVs may be added optionally. However, this does not seem to be the correct interpretation since we already have introduced the OSPFv3 Extended Prefix Range TLV in https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a top-level TLV and may be used for a prefix without its corresponding Inter-Area-Prefix TLV. So we can introduce the SRv6 Locator TLV similar to the Prefix Range TLV into the existing Prefix LSAs as indicated by Acee and there would not be an issue. Thanks, Ketan -Original Message- From: Lsr On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp) Sent: 14 September 2021 12:58 To: Ketan Talaulikar (ketant) ; lsr@ietf.org Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hi Ketan, I'm not against this suggested change. I noticed however, that Acee suggested this a while back and at that time you mentioned an issue when flex-algo locators where advertised this way, see snip below. Can you elaborate on why this is no longer an issue? Thx, Dirk [Acee] Why do you define a separate SRv6 Locator LSA to advertise SRv6 reachability? One of the primary benefits of RFC8362 is to advertise all the information associated with a prefix in one LSA. Now you have negated that benefit by putting this information in a separate LSA. [KT] We need to define a new LSA since this is not an extension for the normal prefix reachability. For doing FlexAlgo with SRv6, the locators are used for reachability computation within the FlexAlgo. If these were advertised as normal prefix reachability then routers which are not part of the FlexAlgo or even routers not supporting SRv6 would program them. We've tried to explain this in https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5. -Original Message- From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Ketan Talaulikar (ketant) Sent: Monday, September 13, 2021 6:29 PM To: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hello All, Some feedback has been received with suggestions to change the encoding currently proposed in the draft - more specifically related to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-02#section-6 The proposal is to do away with the need for introduction of a new LSA for SRv6 Locator and instead advertise the SRv6 Locator as a new top-level TLV within all the extended Prefix LSAs introduced in RFC8362. The advantage is simpler processing for the scenarios where the prefix is advertised as both a normal prefix reachability as well as SRv6 Locator. It also results in avoiding the handling of a new LSA type in OSPFv3. I would like to poll the WG to check if there are any existing implementations of the draft in the current form (even though codepoints have not yet been allocated). Also, if there is any objection to introducing this change. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hi Ketan, I'm not against this suggested change. I noticed however, that Acee suggested this a while back and at that time you mentioned an issue when flex-algo locators where advertised this way, see snip below. Can you elaborate on why this is no longer an issue? Thx, Dirk [Acee] Why do you define a separate SRv6 Locator LSA to advertise SRv6 reachability? One of the primary benefits of RFC8362 is to advertise all the information associated with a prefix in one LSA. Now you have negated that benefit by putting this information in a separate LSA. [KT] We need to define a new LSA since this is not an extension for the normal prefix reachability. For doing FlexAlgo with SRv6, the locators are used for reachability computation within the FlexAlgo. If these were advertised as normal prefix reachability then routers which are not part of the FlexAlgo or even routers not supporting SRv6 would program them. We've tried to explain this in https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5. -Original Message- From: Lsr On Behalf Of Ketan Talaulikar (ketant) Sent: Monday, September 13, 2021 6:29 PM To: lsr@ietf.org Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding Hello All, Some feedback has been received with suggestions to change the encoding currently proposed in the draft - more specifically related to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-02#section-6 The proposal is to do away with the need for introduction of a new LSA for SRv6 Locator and instead advertise the SRv6 Locator as a new top-level TLV within all the extended Prefix LSAs introduced in RFC8362. The advantage is simpler processing for the scenarios where the prefix is advertised as both a normal prefix reachability as well as SRv6 Locator. It also results in avoiding the handling of a new LSA type in OSPFv3. I would like to poll the WG to check if there are any existing implementations of the draft in the current form (even though codepoints have not yet been allocated). Also, if there is any objection to introducing this change. Thanks, Ketan ___ 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] Proposed changes for OSPFv3 SRv6 encoding
Hello All, Some feedback has been received with suggestions to change the encoding currently proposed in the draft - more specifically related to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-02#section-6 The proposal is to do away with the need for introduction of a new LSA for SRv6 Locator and instead advertise the SRv6 Locator as a new top-level TLV within all the extended Prefix LSAs introduced in RFC8362. The advantage is simpler processing for the scenarios where the prefix is advertised as both a normal prefix reachability as well as SRv6 Locator. It also results in avoiding the handling of a new LSA type in OSPFv3. I would like to poll the WG to check if there are any existing implementations of the draft in the current form (even though codepoints have not yet been allocated). Also, if there is any objection to introducing this change. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
