Re: [Lsr] Comments on draft-ietf-lsr-ospfv3-srv6-extensions

[Goethals, Dirk (Nokia - BE/Antwerp)]

LA-flag is fine to be consistent with  RFC8362, lets hear what others have to 
say.
Thx,
Dirk

From: Ketan Talaulikar 
Sent: Thursday, August 11, 2022 6:17 PM
To: Goethals, Dirk (Nokia - BE/Antwerp) 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org; lsr@ietf.org
Subject: Re: Comments on draft-ietf-lsr-ospfv3-srv6-extensions

Hi Dirk,

Please check inline below again with KT2 and I am trimming to limit to the open 
discussion point.


On Thu, Aug 11, 2022 at 9:28 PM Goethals, Dirk (Nokia - BE/Antwerp) 
mailto:dirk.goeth...@nokia.com>> wrote:
KT> The Attached (A/LA) flag was used in RFC8666/8667 for the propagation of 
SRMS advertisements. The question is if that is required or relevant for SRv6 
Locators. There is no harm/issue with introducing a new Attached flag (even if 
I am not sure of its use) and renaming the current Anycast flag to something 
else (e.g., AC?). But perhaps I might be missing something and if so, please 
clarify.

[DG>] I was referring to the text mentioned in RFC8362 chapter 3.1 Prefix 
Options Extensions,
 for the reasons as mentioned in yellow below. As such, it would be equally 
useful for the ABR’s
local ‘node-locators’, unless the ABR is advertising these  local 
‘node-locators’ in all area’s as
route-type 1, is that the plan?

   The prefix options are extended from Appendix 
A.4.1.1<https://datatracker.ietf.org/doc/html/RFC8362#appendix-A.4.1.1> 
[OSPFV3<https://datatracker.ietf.org/doc/html/RFC8362#ref-OSPFV3>].  The
   applicability of the LA-bit is expanded and it SHOULD be set in
   Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when
   the advertised host IPv6 address, i.e., PrefixLength = 128, is an
   interface address.  In RFC 
5340<https://datatracker.ietf.org/doc/html/rfc5340>, the LA-bit is only set in 
Intra-
   Area-Prefix-LSAs (Section 4.4.3.9 in 
[OSPFV3<https://datatracker.ietf.org/doc/html/RFC8362#ref-OSPFV3>]).  This will 
allow a
   stable address to be advertised without having to configure a
   separate loopback address in every OSPFv3 area.


KT2> I now see your point and it is good that you brought that out. In my view, 
the SRv6 locator is associated with the node and not specific to an area 
(though its advertisement could be potentially limited to specific areas by 
policy - e.g., suppressed for summarization). So, it would make things simpler 
if the SRv6 Locator of an ABR were advertised as Type 1 (i.e. Intra-Area) in 
all the attached areas. I believe the Type-1 advertisement handles some 
scenarios better than the attached flag with Type 3. However, if you feel 
strongly about this, we can also include the LA-flag to enable the association 
of SRv6 Locator to a specific area and then advertise as Inter-Area (with 
LA-flag) in other attached areas.

Thanks,
Ketan


Thanks,
Ketan


Regards,
Dirk

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-ietf-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar]

Hi Dirk,

Please check inline below again with KT2 and I am trimming to limit to the
open discussion point.


On Thu, Aug 11, 2022 at 9:28 PM Goethals, Dirk (Nokia - BE/Antwerp) <
dirk.goeth...@nokia.com> wrote:

> KT> The Attached (A/LA) flag was used in RFC8666/8667 for the propagation
> of SRMS advertisements. The question is if that is required or relevant for
> SRv6 Locators. There is no harm/issue with introducing a new Attached flag
> (even if I am not sure of its use) and renaming the current Anycast flag to
> something else (e.g., AC?). But perhaps I might be missing something and if
> so, please clarify.
>
>
>
>
> *[DG>] I was referring to the text mentioned in RFC8362 chapter 3.1 Prefix
> Options Extensions,  for the reasons as mentioned in yellow below. As such,
> it would be equally useful for the ABR’s *
>
> *local ‘node-locators’, unless the ABR is advertising these  local
> ‘node-locators’ in all area’s as *
>
> *route-type 1, is that the plan?*
>
>
>
>The prefix options are extended from Appendix A.4.1.1
>  [OSPFV3
> ].  The
>
>applicability of the LA-bit is expanded and it SHOULD be set in
>
>Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when
>
>the advertised host IPv6 address, i.e., PrefixLength = 128, is an
>
>interface address.  In RFC 5340
> , the LA-bit is only set
> in Intra-
>
>Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3
> ]).  This will
> allow a
>
>stable address to be advertised without having to configure a
>
>separate loopback address in every OSPFv3 area.
>
>
>

KT2> I now see your point and it is good that you brought that out. In my
view, the SRv6 locator is associated with the node and not specific to an
area (though its advertisement could be potentially limited to specific
areas by policy - e.g., suppressed for summarization). So, it would make
things simpler if the SRv6 Locator of an ABR were advertised as Type 1
(i.e. Intra-Area) in all the attached areas. I believe the Type-1
advertisement handles some scenarios better than the attached flag with
Type 3. However, if you feel strongly about this, we can also include the
LA-flag to enable the association of SRv6 Locator to a specific area and
then advertise as Inter-Area (with LA-flag) in other attached areas.

Thanks,
Ketan


>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> Regards,
>
> Dirk
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-ietf-lsr-ospfv3-srv6-extensions

[Goethals, Dirk (Nokia - BE/Antwerp)]

Hi Ketan,
See my responses inline.
Dirk

From: Ketan Talaulikar 
Sent: Thursday, August 11, 2022 4:15 PM
To: Goethals, Dirk (Nokia - BE/Antwerp) 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org; lsr@ietf.org
Subject: Re: Comments on draft-ietf-lsr-ospfv3-srv6-extensions

Hi Dirk,

Thanks for your review and please check inline below for my responses.


On Thu, Aug 11, 2022 at 7:10 PM Goethals, Dirk (Nokia - BE/Antwerp) 
mailto:dirk.goeth...@nokia.com>> wrote:
Hi authors,

I’ve read draft-ietf-lsr-ospfv3-srv6-extensions-06, and have one comment.

In chapter “6.1.  SRv6 Locator TLV” you mention the A-flag, with info similar
to what is mentioned in ISIS. [draft-ietf-lsr-isis-srv6-extensions]

I’m missing the consistency with the other SR drafts for OSPF:
1) We don’t have the A-flag In OSPFv3 SR-MPLS. Either the N-bit [rfc8362] is
set and then the advertised SID is a Node-sid, or it is not set then the 
advertised SID
is an any-cast SID.

KT> You are correct. There is an individual draft that is trying to bring in 
this Anycast Flag for normal prefix reachabilities in both OSPFv2 and v3: 
https://datatracker.ietf.org/doc/html/draft-chen-lsr-anycast-flag-01 ... this 
draft is introducing the Anycast flag only for SRv6 Locators.
[DG>] OK

2) On the other hand, we do have an A-flag (attached flag) in OSPFv2 [RFC7684] 
to indicated
that the advertised SID is local to the ABR/ASBR node but yet in other area/AS. 
Similar the
LA-bit is used in OSPFv3. [rfc8362]

KT> Ack. That is not the Anycast flag.


IMHO, this “attached flag” is missing in this draft unless we modify the 
definition
of the mentioned A-flag in this draft.

KT> The Attached (A/LA) flag was used in RFC8666/8667 for the propagation of 
SRMS advertisements. The question is if that is required or relevant for SRv6 
Locators. There is no harm/issue with introducing a new Attached flag (even if 
I am not sure of its use) and renaming the current Anycast flag to something 
else (e.g., AC?). But perhaps I might be missing something and if so, please 
clarify.

[DG>] I was referring to the text mentioned in RFC8362 chapter 3.1 Prefix 
Options Extensions,
 for the reasons as mentioned in yellow below. As such, it would be equally 
useful for the ABR’s
local ‘node-locators’, unless the ABR is advertising these  local 
‘node-locators’ in all area’s as
route-type 1, is that the plan?

   The prefix options are extended from Appendix 
A.4.1.1<https://datatracker.ietf.org/doc/html/RFC8362#appendix-A.4.1.1> 
[OSPFV3<https://datatracker.ietf.org/doc/html/RFC8362#ref-OSPFV3>].  The
   applicability of the LA-bit is expanded and it SHOULD be set in
   Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when
   the advertised host IPv6 address, i.e., PrefixLength = 128, is an
   interface address.  In RFC 
5340<https://datatracker.ietf.org/doc/html/rfc5340>, the LA-bit is only set in 
Intra-
   Area-Prefix-LSAs (Section 4.4.3.9 in 
[OSPFV3<https://datatracker.ietf.org/doc/html/RFC8362#ref-OSPFV3>]).  This will 
allow a
   stable address to be advertised without having to configure a
   separate loopback address in every OSPFv3 area.


Thanks,
Ketan


Regards,
Dirk

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-ietf-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar]

Hi Dirk,

Thanks for your review and please check inline below for my responses.


On Thu, Aug 11, 2022 at 7:10 PM Goethals, Dirk (Nokia - BE/Antwerp) <
dirk.goeth...@nokia.com> wrote:

> Hi authors,
>
>
>
> I’ve read draft-ietf-lsr-ospfv3-srv6-extensions-06, and have one comment.
>
>
>
> In chapter “6.1.  SRv6 Locator TLV” you mention the A-flag, with info
> similar
>
> to what is mentioned in ISIS. [draft-ietf-lsr-isis-srv6-extensions]
>
>
>
> I’m missing the consistency with the other SR drafts for OSPF:
>
> 1) We don’t have the A-flag In OSPFv3 SR-MPLS. Either the N-bit [rfc8362]
> is
>
> set and then the advertised SID is a Node-sid, or it is not set then the
> advertised SID
>
> is an any-cast SID.
>

KT> You are correct. There is an individual draft that is trying to bring
in this Anycast Flag for normal prefix reachabilities in both OSPFv2 and
v3: https://datatracker.ietf.org/doc/html/draft-chen-lsr-anycast-flag-01
... this draft is introducing the Anycast flag only for SRv6 Locators.


> 2) On the other hand, we do have an A-flag (attached flag) in OSPFv2
> [RFC7684] to indicated
>
> that the advertised SID is local to the ABR/ASBR node but yet in other
> area/AS. Similar the
>
> LA-bit is used in OSPFv3. [rfc8362]
>

KT> Ack. That is not the Anycast flag.


>
>
> IMHO, this “attached flag” is missing in this draft unless we modify the
> definition
>
> of the mentioned A-flag in this draft.
>

KT> The Attached (A/LA) flag was used in RFC8666/8667 for the propagation
of SRMS advertisements. The question is if that is required or relevant for
SRv6 Locators. There is no harm/issue with introducing a new Attached flag
(even if I am not sure of its use) and renaming the current Anycast flag to
something else (e.g., AC?). But perhaps I might be missing something and if
so, please clarify.

Thanks,
Ketan


>
>
> Regards,
>
> Dirk
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Comments on draft-ietf-lsr-ospfv3-srv6-extensions

[Goethals, Dirk (Nokia - BE/Antwerp)]

Hi authors,

I've read draft-ietf-lsr-ospfv3-srv6-extensions-06, and have one comment.

In chapter "6.1.  SRv6 Locator TLV" you mention the A-flag, with info similar
to what is mentioned in ISIS. [draft-ietf-lsr-isis-srv6-extensions]

I'm missing the consistency with the other SR drafts for OSPF:
1) We don't have the A-flag In OSPFv3 SR-MPLS. Either the N-bit [rfc8362] is
set and then the advertised SID is a Node-sid, or it is not set then the 
advertised SID
is an any-cast SID.
2) On the other hand, we do have an A-flag (attached flag) in OSPFv2 [RFC7684] 
to indicated
that the advertised SID is local to the ABR/ASBR node but yet in other area/AS. 
Similar the
LA-bit is used in OSPFv3. [rfc8362]

IMHO, this "attached flag" is missing in this draft unless we modify the 
definition
of the mentioned A-flag in this draft.

Regards,
Dirk

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Comments on draft-ietf-lsr-ospfv3-srv6-extensions

[chen.ran]

Hi authors,






 I've read 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/, and  
this is a useful work. Thanks.


 But I have a   comment :






The recommended allocation type in section 12.3  conflicts with the existing 
allocated type,please see below.
















Please Check it.






Best Regards,


Ran___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr