Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 13 Sep 2021 16:28:55 +0000

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

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 14 Sep 2021 07:27:53 +0000

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

<snip>
[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 <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Monday, September 13, 2021 6:29 PM
To: [email-masked]
Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Hello All,

Thanks,
Ketan

_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 14 Sep 2021 07:55:56 +0000

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 <[email-masked]> On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp)
Sent: 14 September 2021 12:58
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; [email-masked]
Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Hi Ketan,

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

<snip>

[Acee]

-----Original Message-----

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Ketan Talaulikar (ketant)

To: [email-masked]<mailto:[email-masked]>

Hello All,

Thanks,

Ketan

Lsr mailing list

[email-masked]<mailto:[email-masked]>

Lsr mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 14 Sep 2021 08:45:27 +0000

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) <[email-masked]>
Sent: Tuesday, September 14, 2021 9:56 AM
To: Goethals, Dirk (Nokia - BE/Antwerp) <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; [email-masked]
Subject: RE: Proposed changes for OSPFv3 SRv6 encoding

Hi Dirk,

   In order to retain

Thanks,

Ketan

-----Original Message-----
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp)
Sent: 14 September 2021 12:58
To: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Hi Ketan,

Thx,

Dirk

<snip>

[Acee]

-----Original Message-----

Hello All,

Thanks,

Ketan

Lsr mailing list

Lsr mailing list

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 14 Sep 2021 09:24:49 +0000

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) <[email-masked]>
Sent: 14 September 2021 14:15
To: Ketan Talaulikar (ketant) <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; [email-masked]
Subject: RE: Proposed changes for OSPFv3 SRv6 encoding

Hi Ketan,

I'm I missing something?
Thx,
Dirk

From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 14, 2021 9:56 AM
To: Goethals, Dirk (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Proposed changes for OSPFv3 SRv6 encoding

Hi Dirk,

   In order to retain

Thanks,

Ketan

-----Original Message-----
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Goethals, Dirk (Nokia - BE/Antwerp)
Sent: 14 September 2021 12:58
To: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Hi Ketan,

Thx,

Dirk

<snip>

[Acee]

-----Original Message-----

Hello All,

Thanks,

Ketan

Lsr mailing list

Lsr mailing list

---

From: Peter Psenak <[email-masked]>
Date: Tue, 14 Sep 2021 11:52:19 +0200

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.
> 
> 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) <[email-masked]>
> *Sent:* 14 September 2021 14:15
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; Ketan Talaulikar 
> (ketant) <ketant=[email-masked]>; [email-masked]
> *Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding
> 
> Hi Ketan,
> 
> I’m not sure I understand your reply correctly.
> 
>     it is treated as malformed as described in Section 5 
> <https://datatracker.ietf.org/doc/html/rfc8362#section-5>.
> 
> I’ve been told that the NU-bit 
> (https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1)
> 
> I’m I missing something?
> *From:*Ketan Talaulikar (ketant) <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Tuesday, September 14, 2021 9:56 AM
> *To:* Goethals, Dirk (Nokia - BE/Antwerp) <[email-masked] 
> <mailto:[email-masked]>>; Ketan Talaulikar (ketant) 
> <ketant=[email-masked] 
> <mailto:ketant=[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *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.
> 
> 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
> 
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf 
> Of Goethals, Dirk (Nokia - BE/Antwerp)
> To: Ketan Talaulikar (ketant) <ketant=[email-masked] 
> <mailto:ketant=[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> 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
> 
> <snip>
> 
> [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.
> 
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf 
> Of Ketan Talaulikar (ketant)
> 
> To: [email-masked] <mailto:[email-masked]>
> 
> 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
> 
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
>

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 14 Sep 2021 10:56:28 +0000

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 <[email-masked]> 
Sent: Tuesday, September 14, 2021 11:52 AM
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Goethals, Dirk (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Hi Ketan,

On 14/09/2021 11:24, Ketan Talaulikar (ketant) wrote:
> 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 
> 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
> 

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

> 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
> 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
> 
> From: Lsr <[email-masked] <mailto:[email-masked]>> On 
> Behalf Of Goethals, Dirk (Nokia - BE/Antwerp)
> this way, see snip below. Can you elaborate on why this is no longer 
> an issue?
> 
> Thx,
> 
> Dirk
> 
> <snip>
> 
> [Acee]
> 
> reachability? One of the primary benefits of RFC8362 is to advertise 
> all the information associated with a prefix in one LSA. Now you have 
> [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.
> From: Lsr <[email-masked] <mailto:[email-masked]>> On 
> Behalf Of Ketan Talaulikar (ketant)
> 
> Some feedback has been received with suggestions to change the 
> encoding currently proposed in the draft - more specifically related 
> to
> 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
>