Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

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

Hi Ketan,
The update looks good to me.
Thx,
Dirk

From: Lsr  On Behalf Of Ketan Talaulikar
Sent: Tuesday, August 23, 2022 8:02 PM
To: Acee Lindem (acee) 
Cc: lsr ; draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org; 
Goethals, Dirk (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi Acee/Dirk,

The updated version posted earlier today addresses Dirk's comments and was 
announced to the LSR WG list: 
https://mailarchive.ietf.org/arch/msg/lsr/Tv0_jfa05wT1YWd6PG00eFrWXZQ/

Please let me know if there are any further changes/updates pending.

Thanks,
Ketan


On Wed, Aug 17, 2022 at 9:08 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Wednesday, August 17, 2022 at 11:35 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 "Goethals, Dirk (Nokia - BE/Antwerp)" 
mailto:dirk.goeth...@nokia.com>>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi Acee,

The routing for anycast is transparent but there are features and use cases 
where the knowledge of Anycast is required or helpful. I don't have all the 
draft pointers, but there have been presentations in SPRING and RTGWG WGs on 
redundancy and protection features that leverage anycast.

I think we’re agreeing, I’ve seen the same use case presentations and it is, 
IMO, a far better usage than prefix unreachability 😉

Thanks,
Acee

Thanks,
Ketan


On Wed, Aug 17, 2022 at 8:44 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Wednesday, August 17, 2022 at 11:04 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 "Goethals, Dirk (Nokia - BE/Antwerp)" 
mailto:dirk.goeth...@nokia.com>>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi Acee,

Please check inline below.


On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Wednesday, August 17, 2022 at 9:48 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 "Goethals, Dirk (Nokia - BE/Antwerp)" 
mailto:dirk.goeth...@nokia.com>>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hello Acee/All,

There has not been any further comment/feedback on the point that Dirk brought 
up in the thread below:
https://mailarchive.ietf.org/arch/msg/lsr/_4HcJEsteNQxjxuot1uLdoXeH6s/

I want to point out that not just the LA-flag, but also the P-flag is required 
for propagation of the SRv6 Locator LSA across NSSA.

Perhaps the best option available to us is to replace the "Flags" field in the 
SRv6 Locator TLV (refer to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-06#section-6.1)
 with the "PrefixOptions" field that is present in all the OSPFv3 prefix 
reachability advertisements in RFC5340/8362. This will also bring a nice 
consistency for OSPFv3 even though some flags are unused in the SRv6 context.

We only have 1 bit left - 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4
 So, perhaps we need to add the PrefixOptions using the existing registry and 
we need a new field and registry that could be advertised in Extended LSAs.

KT> This is the idea behind 
https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/ - hopefully, we 
can bring it up for WG adoption soon. I believe Anycast is a strong enough use 
case to consume the remaining unused bit and the introduction of a new 
extensible Flags sub-TLV should take care of future extensions as proposed in 
the aforementioned individual draft.

Is this the first introduction of the N flag for OSPFv3 in any LSA? I don’t see 
it in https://datatracker.ietf.org/doc/rfc8666/

KT> N flag in PrefixOptio

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

[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

[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

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

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

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

[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] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

I think we are in sync, i.e.
without this draft there is no use-case for node T1 to send an
AS-scoped router info LSA without being ASBR.
Please correct if you know of an existing use-case.
Thx,
Dirk

On 2/18/2019 15:01, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 14:47 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
Hi Peter,
and you use these when you send a traffic to some of the prefixes that
T1 originates

If T1 is not ASBR,  and this draft is not implemented, how are the nodes
in the
other area's going to know that the prefixes belong to T1?

that is exactly what this draft is trying to address. Today there is no way to 
determine the originator of the prefix in the remote area. We are adding that 
functionality in this draft.

thanks,
Peter

Dirk


On 2/18/2019 14:34, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 14:27 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
support +1

1 question:

When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label
stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

yes, that is a possibility.


If so, should T1 be ASBR as to be able to send this AS-scoped LSA?

I would not think so.
DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.

if the T1 advertises some properties in it's AS-scoped LSA and you use
these when you send a traffic to some of the prefixes that T1
originates, then you don't really need to know where it is located,
you only care about its properties.





I guess it was needed before as to enforce  the ABR to create the T4
LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

not sure how you reached the above conclusion. Can you please clarify?
DG> Since the ABR is adding the originator, one can indirectly learn
that
the originator is also reachable via this ABR.

well, I don't think we want to replace the Type-4 LSA functionality
with the Prefix-Originator.

thanks,
Peter


thanks,
Peter




Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one
<https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext><https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext>

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext



It is listed multiple times but references the same CN201810650141.



Thanks,

Acee




___
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] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

Hi Peter,
and you use these when you send a traffic to some of the prefixes that T1 
originates

If T1 is not ASBR,  and this draft is not implemented, how are the nodes in the
other area's going to know that the prefixes belong to T1?
Dirk


On 2/18/2019 14:34, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 14:27 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
support +1

1 question:

When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label
stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

yes, that is a possibility.


If so, should T1 be ASBR as to be able to send this AS-scoped LSA?

I would not think so.
DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.

if the T1 advertises some properties in it's AS-scoped LSA and you use these 
when you send a traffic to some of the prefixes that T1 originates, then you 
don't really need to know where it is located, you only care about its 
properties.





I guess it was needed before as to enforce  the ABR to create the T4
LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

not sure how you reached the above conclusion. Can you please clarify?
DG> Since the ABR is adding the originator, one can indirectly learn that
the originator is also reachable via this ABR.

well, I don't think we want to replace the Type-4 LSA functionality with the 
Prefix-Originator.

thanks,
Peter


thanks,
Peter




Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one
<https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext><https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext>
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext


It is listed multiple times but references the same CN201810650141.



Thanks,

Acee




___
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] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

I agree with Peter.
For this to work, the ABR would need to add ALL originators, while I
had the impression that we only had 1 originator per prefix,
i.e. the originator which was found to be the closed to the ABR and
for which the ABR installed a route.

Dirk


On 2/18/2019 14:15, Peter Psenak wrote:
Support as coauthor, although I never really agreed with the usage of the 
prefix originator for topology construction as described  in section 3 and 5. I 
would prefer that part to be removed.

thanks,
Peter


On 13/02/2019 14:25 , Acee Lindem (acee) wrote:
This begins a two week adoption poll for the subject draft. Please send
your comments to this list before 12:00 AM UTC on Thursday, February
28^th , 2019.



All authors have responded to the IPR poll and there is one

 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext

It is listed multiple times but references the same CN201810650141.



Thanks,

Acee





___
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] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
support +1

1 question:

When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

yes, that is a possibility.


If so, should T1 be ASBR as to be able to send this AS-scoped LSA?

I would not think so.
DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.


I guess it was needed before as to enforce  the ABR to create the T4 LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

not sure how you reached the above conclusion. Can you please clarify?
DG> Since the ABR is adding the originator, one can indirectly learn that
the originator is also reachable via this ABR.

thanks,
Peter




Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one
<https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext><https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext>
 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext

It is listed multiple times but references the same CN201810650141.



Thanks,

Acee




___
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] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

support +1

1 question:


When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

If so, should T1 be ASBR as to be able to send this AS-scoped LSA?
I guess it was needed before as to enforce  the ABR to create the T4 LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:
This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one 

  
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee




___
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] advertising tunnels in IGP

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

Hi Alexander, Acee, Peter,
Thanks for your prompt suggestions.

Alexander,
I’m also in favor of having something as simple as in OSPFV2.
So, I’m somewere on the same track as you, i.e.
1) a flexible bidirectional check when nbrid=0, similar as unnumbered p2p in 
OSPFv2
2) during next hop resolution, when nbrid=0, pick up the local tunnelinfo iso 
neigbors
ip address.

Thanks,
Dirk

_
From: Alexander Okonnikov 
Sent: donderdag, maart 1, 2018 6:54 PM
Subject: Re: [Lsr] advertising tunnels in IGP
To: Acee Lindem (acee) , Goethals, Dirk (Nokia - BE/Antwerp) 
, 



Hi,

I cannot find in RFC 5340 where pair of Interface ID/Neighbor Interface ID are 
used for two-way check for P2P link. RFC 5340 reuses SPF algorithm from RFC 
2328. RFC 2328 says that W should have link back to V, but it also says (in 
footnote 23) that link from W to V does not necessarily matches to link from V 
to W. I.e. presence of two unidirectional links is enough for two-way check to 
be passed. Is it correct?

If yes then, what if OSPFv3 router will set Neighbor Interface ID to 0 for P2P 
link and the neighbor will do the same? How it will be treated by other routers 
while calculate SPF?

Also, Neighbor Interface ID is used as reference for corresponding Link LSA 
while calculating next-hop. Per my understanding neighbor's IPv6 link-local 
address is not needed (as well as neighbor's Link LSA), because LSP will be 
next-hop in this case.

Thanks.

01.03.2018 20:08, Alexander Okonnikov пишет:

Hi,

Need for advertising of FA by both sides is dictated by OSPFv2 and IS-IS, 
because they 1) check presence of adjacency in two directions and 2) cannot 
distinguish FA from regular P2P link. If latter was possible, then it would not 
be needed to perform two-way check for FA (presence of FA just in forward 
direction means that ingress "link" on remote neighbor is working; otherwise 
LSP in forward direction would be broken). It can be generalized to all three 
protocols: if we can somehow identify link type as FA, we don't need two-way 
check for FA. We also don't need Neighbor Interface ID for FA in OSPFv3 in this 
case.

Thank you.

01.03.2018 19:56, Acee Lindem (acee) пишет:
Hi Alexander,

From:Alexander Okonnikov 
<mailto:alexander.okonni...@gmail.com>
Date: Thursday, March 1, 2018 at 11:40 AM
To: "Goethals, Dirk (Nokia - BE/Antwerp)" 
<mailto:dirk.goeth...@nokia.com>, 
"lsr@ietf.org"<mailto:lsr@ietf.org> <mailto:lsr@ietf.org>, Acee 
Lindem<mailto:a...@cisco.com>
Subject: Re: [Lsr] advertising tunnels in IGP

Hi,

I think that problem here is that two LSPs are two independent unidirectional 
links, rather than one bidirectional. Moreover, LSPs in two directions are not 
pairs (some two LSPs are not associated to each other), and amount of LSPs in 
each direction is not necessary the same. I could assume that some router uses 
Interface IDs for two-way check, but it is not so straightforward when we have 
deal with FAs.

Acee, two-way check could be disabled on the router that is owner of FA, but 
how other routers will distinguish regular P2P from FA?

Good point – all the transit routers need to agree on the interface IDs.

Thanks,
Acee


Thank you.

Best regards,
Alexander Okonnikov

1 марта 2018 г., 19:37 +0300, Acee Lindem (acee) 
<mailto:a...@cisco.com>, писал:

Hi Dirk,

My memory has faded somewhat on Forwarding Adjacency (FA) implementation. 
However, since basic MPLS LSPs are unidirectional, doesn’t the SPF two-way 
check have to be disabled anyway? If so, the Remote Interface ID doesn’t matter.

Thanks,
Acee

From:Lsr <mailto:lsr-boun...@ietf.org> on behalf of 
"Goethals, Dirk (Nokia - BE/Antwerp)" 
<mailto:dirk.goeth...@nokia.com>
Date: Thursday, March 1, 2018 at 11:06 AM
To: "lsr@ietf.org"<mailto:lsr@ietf.org><mailto:lsr@ietf.org>
Subject: [Lsr] advertising tunnels in IGP

Hi,
In OSPFv2 (and ISIS), we can add (RSVP) tunnels to the topology
by adding them as a unnumbered link in the router lsa.
In OSPFv3, we can only add a link to the router-lsa if the neighbor
interface ID is known.
So it looks like we can only add a tunnel to the OSPFv3 topology,
if we first exchanging hello packets over the tunnel.
Is that correct?
As this is not needed in the other IGPs, do
we have other possibilities?
Thx,
Dirk


___
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] advertising tunnels in IGP

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

Peter,
Indeed.
Thx,
Dirk

Outlook voor Android<https://aka.ms/ghei36> downloaden


From: Peter Psenak 
Sent: Thursday, March 1, 2018 5:21:13 PM
To: Goethals, Dirk (Nokia - BE/Antwerp); lsr@ietf.org
Subject: Re: [Lsr] advertising tunnels in IGP

Hi Dirk,


On 01/03/18 17:05 , Dirk Goethals wrote:
> Hi,
> In OSPFv2 (and ISIS), we can add (RSVP) tunnels to the topology
> by adding them as a unnumbered link in the router lsa.
> In OSPFv3, we can only add a link to the router-lsa if the neighbor
> interface ID is known.
> So it looks like we can only add a tunnel to the OSPFv3 topology,
> if we first exchanging hello packets over the tunnel.
> Is that correct?
> As this is not needed in the other IGPs, do
> we have other possibilities?

well, one can manually configure the local/remote interface IDs to match
on both sides and advertise as such.

thanks,
Peter
> Thx,
> Dirk
>
>
>
>
> ___
> 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