date:20210914

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

2021-09-14 Thread Goethals, Dirk (Nokia - BE/Antwerp)

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 
> .
> 
> 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/rf

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

2021-09-14 Thread Peter Psenak


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 
.


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) >; 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 putti

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

2021-09-14 Thread Ketan Talaulikar (ketant)

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.

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
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
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 p

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

2021-09-14 Thread Goethals, Dirk (Nokia - BE/Antwerp)

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.

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
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

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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

2021-09-14 Thread Ketan Talaulikar (ketant)

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

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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

2021-09-14 Thread Goethals, Dirk (Nokia - BE/Antwerp)

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

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

6 matches

Site Navigation

Mail list logo

Footer information