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

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

2022-08-29 Thread Ketan Talaulikar

Hi Dirk,

Thanks again for your review and confirmation.

Thanks,
Ketan


On Mon, Aug 29, 2022 at 4:31 PM Goethals, Dirk (Nokia - BE/Antwerp) <
dirk.goeth...@nokia.com> wrote:

> 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)  wrote:
>
> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Wednesday, August 17, 2022 at 11:35 AM
> *To: *Acee Lindem 
> *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,
>
>
>
> 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)  wrote:
>
> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Wednesday, August 17, 2022 at 11:04 AM
> *To: *Acee Lindem 
> *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,
>
>
>
> Please check inline below.
>
>
>
>
>
> On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee)  wrote:
>
> Hi Ketan,
>
>
>
> *From: *Lsr  on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Wednesday, August 17, 2022 at 9:48 AM
> *To: *Acee Lindem 
> *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)
>
>
>
> 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 dra

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

2022-08-29 Thread 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 PrefixOptions came vi

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

2022-08-24 Thread Ketan Talaulikar

Hi Shraddha,

Thanks for the confirmation. These changes have been already reflected in
the latest version.

Thanks,
Ketan


On Thu, Aug 25, 2022 at 9:19 AM Shraddha Hegde  wrote:

> Snipped to open comments.
>
>
>
> KT> Since we are talking about SRv6 Locators, that are associated with the
> node and not a LAN, I am not sure these fields hold much relevance. Please
> let me know if I am missing something.
>
>  I agree there is no relevance, but its important to specify there is
> no relevance and describe what should be filled while sending.
>
>
>
> KT2> We don't have these fields in the SRv6 Locator TLV so there is
> nothing to be filled in there. I believe you are suggesting clarification
> on how these fields need to be filled when an SRv6 Locator is also
> advertised as "normal" prefix reachability using the Intra-Area-Prefix TLV
> in the E-Intra-Area-Prefix LSA (e.g., for algo 0). Can you please confirm?
>
>
>
>  Yes. That is correct.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar 
> *Sent:* Monday, August 22, 2022 10:23 AM
> *To:* Shraddha Hegde 
> *Cc:* Yingzhen Qu ; Acee Lindem (acee)  40cisco....@dmarc.ietf.org>; lsr ;
> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for
> SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Shraddha,
>
>
>
> Thanks for your response. Please check inline below with KT2 for some
> clarifications.
>
>
>
> We'll work on posting the update once this one remaining discussion point
> is closed.
>
>
>
>
>
> On Mon, Aug 22, 2022 at 9:46 AM Shraddha Hegde 
> wrote:
>
> Hi Ketan,
>
>
>
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, August 18, 2022 11:28 PM
> *To:* Shraddha Hegde 
> *Cc:* Yingzhen Qu ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>; lsr ;
> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for
> SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Shraddha,
>
>
>
> Thanks for your detailed review and please check inline below for
> responses.
>
>
>
>
>
> On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde 
> wrote:
>
> Authors,
>
> OSPFv3 extensions for Srv6 is a useful draft and I support progressing
> this draft.
> I have below comments.
>
>
>
>   1. Add a section to describe benefits of defining a new locator LSA
> rather than
>  putting locator sub-TLV in existing LSAs.
>
>
>
> KT> I do not personally see a significant benefit in using a new LSA as
> opposed to re-using existing ones. When this draft was originally proposed,
> we (authors) were not able to use the base extended prefix LSAs due to the
> mandatory requirement for using the base prefix reachability TLVs per
> RFC8362. Hence, we went with the new LSAs so as not to mix up the
> reachabilities and follow RFC8362. However, after further discussions in
> the WG, there were newer methods determined (e.g., the use of LSInfinity as
> a metric for the base prefix reachability TLVs that we are doing for OSPFv3
> IP FlexAlgo). However, by then there were already implementations using the
> new LSAs for OSPFv3 SRvt, so it was decided to continue with the approach
> of using the new LSAs.
>
>
>
>  OK
>
>
>
> 2.
> "The processing of the prefix
>   advertised in the SRv6 Locator TLV, the calculation of its
>   reachability, and the installation in the forwarding plane follows
>   the OSPFv3 [RFC5340] specifications for the respective route types.
>   Locators associated with algorithms 0 and 1 SHOULD be advertised
>   using the respective OSPFv3 Extended LSA types with extended TLVs
>   [RFC8362] so that routers that do not support SRv6 will install a
>   forwarding entry for SRv6 traffic matching those locators.  When
>   operating in Extended LSA sparse-mode [RFC8362], these locators
>   SHOULD be also advertised using the respective legacy OSPFv3 LSAs
>   [RFC5340]."
>
>I suggest to change the SHOULD to MUST
>and always use legacy LSAs/extended LSAs for reachability
>   calculation for algo 0 and algo 1.
>   The current text says use legacy LSAs/extended LSAs if its
> there.
>
>
>
> KT> The usage of SHOULD is aligne

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

2022-08-24 Thread Shraddha Hegde

Snipped to open comments.

KT> Since we are talking about SRv6 Locators, that are associated with the node 
and not a LAN, I am not sure these fields hold much relevance. Please let me 
know if I am missing something.
 I agree there is no relevance, but its important to specify there is no 
relevance and describe what should be filled while sending.

KT2> We don't have these fields in the SRv6 Locator TLV so there is nothing to 
be filled in there. I believe you are suggesting clarification on how these 
fields need to be filled when an SRv6 Locator is also advertised as "normal" 
prefix reachability using the Intra-Area-Prefix TLV in the E-Intra-Area-Prefix 
LSA (e.g., for algo 0). Can you please confirm?

 Yes. That is correct.



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Monday, August 22, 2022 10:23 AM
To: Shraddha Hegde 
Cc: Yingzhen Qu ; Acee Lindem (acee) 
; lsr ; 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your response. Please check inline below with KT2 for some 
clarifications.

We'll work on posting the update once this one remaining discussion point is 
closed.


On Mon, Aug 22, 2022 at 9:46 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, August 18, 2022 11:28 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; lsr 
mailto:lsr@ietf.org>>; 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

Hi Shraddha,

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


On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Authors,

OSPFv3 extensions for Srv6 is a useful draft and I support progressing this 
draft.
I have below comments.



  1. Add a section to describe benefits of defining a new locator LSA rather 
than
 putting locator sub-TLV in existing LSAs.

KT> I do not personally see a significant benefit in using a new LSA as opposed 
to re-using existing ones. When this draft was originally proposed, we 
(authors) were not able to use the base extended prefix LSAs due to the 
mandatory requirement for using the base prefix reachability TLVs per RFC8362. 
Hence, we went with the new LSAs so as not to mix up the reachabilities and 
follow RFC8362. However, after further discussions in the WG, there were newer 
methods determined (e.g., the use of LSInfinity as a metric for the base prefix 
reachability TLVs that we are doing for OSPFv3 IP FlexAlgo). However, by then 
there were already implementations using the new LSAs for OSPFv3 SRvt, so it 
was decided to continue with the approach of using the new LSAs.

 OK

2.
"The processing of the prefix
  advertised in the SRv6 Locator TLV, the calculation of its
  reachability, and the installation in the forwarding plane follows
  the OSPFv3 [RFC5340] specifications for the respective route types.
  Locators associated with algorithms 0 and 1 SHOULD be advertised
  using the respective OSPFv3 Extended LSA types with extended TLVs
  [RFC8362] so that routers that do not support SRv6 will install a
  forwarding entry for SRv6 traffic matching those locators.  When
  operating in Extended LSA sparse-mode [RFC8362], these locators
  SHOULD be also advertised using the respective legacy OSPFv3 LSAs
  [RFC5340]."

   I suggest to change the SHOULD to MUST
   and always use legacy LSAs/extended LSAs for reachability
  calculation for algo 0 and algo 1.
  The current text says use legacy LSAs/extended LSAs if its there.

KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*section-5__;Iw!!NEt6yMaO-gk!F5ePU2u8gidMUa5UIGC_tSJ6PeNxoOhrD6NgqAHhxZ7Pk487kQLvCJuHJdmtzGeVlQJ0aMsTGgoiZbjikKYjlA$>).

 If we decide to keep congruent with ISIS, that's fine
I noticed that section corresponding to below is missing in OSPF

"Locators associated with Flexible Algorithms (see Section 4 of
   
[I-D.ietf-lsr-flex-algo<https://urldefense.com/v3/__htt

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

2022-08-23 Thread Acee Lindem (acee)

The Working Group Last Call (WGLC) has completed. There is more than sufficient 
support for publication. As result of the WGLC discussion, there have been some 
changes and these reflected in the -07 version.


https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07

Please review the changes resulting from the WGLC discussion. Note that the 
locator TLV will now use the PrefixOptions field common to other OSPFv3 LSAs 
advertising prefixes and will contain the Anycast (AC-bit). This change is 
reflected in sections 6 and 7.1.

Thanks,
Acee


From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, July 29, 2022 at 1:18 PM
To: lsr 
Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

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

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

2022-08-23 Thread Ketan Talaulikar

Hi Shraddha,

I have not yet received your response to my email below. However, we've
gone ahead with the updates as discussed below and it was posted a short
while ago:
https://mailarchive.ietf.org/arch/msg/lsr/Tv0_jfa05wT1YWd6PG00eFrWXZQ/

Please let us know if there are any further comments pending to be
addressed.

Thanks,
Ketan


On Mon, Aug 22, 2022 at 10:22 AM Ketan Talaulikar 
wrote:

> Hi Shraddha,
>
> Thanks for your response. Please check inline below with KT2 for some
> clarifications.
>
> We'll work on posting the update once this one remaining discussion point
> is closed.
>
>
> On Mon, Aug 22, 2022 at 9:46 AM Shraddha Hegde 
> wrote:
>
>> Hi Ketan,
>>
>>
>>
>> Pls see inline..
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* Ketan Talaulikar 
>> *Sent:* Thursday, August 18, 2022 11:28 PM
>> *To:* Shraddha Hegde 
>> *Cc:* Yingzhen Qu ; Acee Lindem (acee) > 40cisco....@dmarc.ietf.org>; lsr ;
>> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for
>> SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hi Shraddha,
>>
>>
>>
>> Thanks for your detailed review and please check inline below for
>> responses.
>>
>>
>>
>>
>>
>> On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde 
>> wrote:
>>
>> Authors,
>>
>> OSPFv3 extensions for Srv6 is a useful draft and I support progressing
>> this draft.
>> I have below comments.
>>
>>
>>
>>   1. Add a section to describe benefits of defining a new locator LSA
>> rather than
>>  putting locator sub-TLV in existing LSAs.
>>
>>
>>
>> KT> I do not personally see a significant benefit in using a new LSA as
>> opposed to re-using existing ones. When this draft was originally proposed,
>> we (authors) were not able to use the base extended prefix LSAs due to the
>> mandatory requirement for using the base prefix reachability TLVs per
>> RFC8362. Hence, we went with the new LSAs so as not to mix up the
>> reachabilities and follow RFC8362. However, after further discussions in
>> the WG, there were newer methods determined (e.g., the use of LSInfinity as
>> a metric for the base prefix reachability TLVs that we are doing for OSPFv3
>> IP FlexAlgo). However, by then there were already implementations using the
>> new LSAs for OSPFv3 SRvt, so it was decided to continue with the approach
>> of using the new LSAs.
>>
>>
>>
>>  OK
>>
>>
>>
>> 2.
>> "The processing of the prefix
>>   advertised in the SRv6 Locator TLV, the calculation of its
>>   reachability, and the installation in the forwarding plane follows
>>   the OSPFv3 [RFC5340] specifications for the respective route types.
>>   Locators associated with algorithms 0 and 1 SHOULD be advertised
>>   using the respective OSPFv3 Extended LSA types with extended TLVs
>>   [RFC8362] so that routers that do not support SRv6 will install a
>>   forwarding entry for SRv6 traffic matching those locators.  When
>>   operating in Extended LSA sparse-mode [RFC8362], these locators
>>   SHOULD be also advertised using the respective legacy OSPFv3 LSAs
>>   [RFC5340]."
>>
>>I suggest to change the SHOULD to MUST
>>and always use legacy LSAs/extended LSAs for reachability
>>   calculation for algo 0 and algo 1.
>>   The current text says use legacy LSAs/extended LSAs if its
>> there.
>>
>>
>>
>> KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*section-5__;Iw!!NEt6yMaO-gk!F5ePU2u8gidMUa5UIGC_tSJ6PeNxoOhrD6NgqAHhxZ7Pk487kQLvCJuHJdmtzGeVlQJ0aMsTGgoiZbjikKYjlA$>
>> ).
>>
>>
>>
>>  If we decide to keep congruent with ISIS, that’s fine
>>
>> I noticed that section corresponding to below is missing in OSPF
>>
>> “Locators associated with Flexible Algorithms (see Section 4 of
>>
>>[I-D.ietf-lsr-flex-algo
>> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#ref-I-D.ietf-lsr-flex-algo>])
>> SHOULD NOT be advertised in Prefix
>

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

2022-08-23 Thread Ketan Talaulikar

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)  wrote:

> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Wednesday, August 17, 2022 at 11:35 AM
> *To: *Acee Lindem 
> *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,
>
>
>
> 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)  wrote:
>
> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Wednesday, August 17, 2022 at 11:04 AM
> *To: *Acee Lindem 
> *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,
>
>
>
> Please check inline below.
>
>
>
>
>
> On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee)  wrote:
>
> Hi Ketan,
>
>
>
> *From: *Lsr  on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Wednesday, August 17, 2022 at 9:48 AM
> *To: *Acee Lindem 
> *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)
>
>
>
> 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 PrefixOptions came via RFC8362 and so RFC8666 didn't have to
> do anything about it. Refer
> https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4
>
>
>
>
>
> Ok – I thought I remembered the N-Flag but I didn’t look close enough at
> the existing IANA assignments. I agree we can use the add the Anycast Bit
> to the Prefix Options. Although it seems to negate the fact that anycast
> can be routed transparently, there are enough drafts presenting use cases
> as to why it is needed.
>
>
>
> Thanks,
> Acee
>
>

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

2022-08-23 Thread Ketan Talaulikar

Hi Dhruv,

Thanks for your review and feedback. Will incorporate your suggestions in
the upcoming update.

Thanks,
Ketan


On Mon, Aug 22, 2022 at 7:54 PM Dhruv Dhody  wrote:

> Hi,
>
> I support WG LC. It is in good shape!
>
> It might be a good idea to include some text (perhaps in the appendix) on
> why a new LSA is used for SRv6 Locator LSA. Any reviewer and future reader
> would wonder why this decison was made.
>
> BTW, do expand LSA on first use.
>
> Thanks!
> Dhruv
>
> On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
>> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
>> extra week is to account for PIST (Post-IETF Stress Syndrome). The
>> corresponding IS-IS draft is already on the RFC Queue and there are
>> implementations.
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Acee & Chris
>>
>>
>>
>>
>> ___
>> 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 Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

2022-08-22 Thread Dhruv Dhody

Hi,

I support WG LC. It is in good shape!

It might be a good idea to include some text (perhaps in the appendix) on
why a new LSA is used for SRv6 Locator LSA. Any reviewer and future reader
would wonder why this decison was made.

BTW, do expand LSA on first use.

Thanks!
Dhruv

On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee)  wrote:

> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
> extra week is to account for PIST (Post-IETF Stress Syndrome). The
> corresponding IS-IS draft is already on the RFC Queue and there are
> implementations.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
> ___
> 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 Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

2022-08-22 Thread Acee Lindem (acee)

Speaking as WG Member:

Hi Aijun, Zhibo,

From: Huzhibo 
Date: Friday, August 19, 2022 at 6:27 AM
To: Aijun Wang , Acee Lindem , 'lsr' 

Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

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

Hi Aijun,

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

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 19, 2022 5:55 PM
To: 'Acee Lindem (acee)' ; 'lsr' 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi, All:
 I have the following comments for this draft, and would like to support 
its forwarding when the below concerns are addressed.

1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
  There are situations that such information can be utilized by the routers 
within the area, as I presented at the IETF 114 meeting (the draft is pending 
to be updated).  Then the following sentence:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-
   Router-Link TLV.”

Should be relaxed as:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
Neighbor/Link related TLVs.”

Zhibo> This description does not affect the new TLVs. If a new TLV is added, 
you can include the sub TLV in the new TLV.

2. Support for the “SRv6 Locator TLV” to be included within the existing 
LSA, rather than to define the new “Locator LSA”.

Zhibo> The reason for defining new LSAs is to prevent processing errors on 
nodes that do not support SRv6. For example, ignoring algorithm fields may 
cause loops.

Of course, using LSinfinity metric is one way to solve this problem, but the 
protocol specifies the IGP does not generate the RIB/Fib for LSinfinity Metric 
prefix.

The LSinfinity metric does not meet this scenario. In addition, IS-IS also 
defines a New TOP TLV. The OSPF definition is the same as that of IS-IS.

While either encoding could work, I agree that this may be cleaner since  the 
separation readily allows knowing whether the SRv6 or base LSA changed. 
Additionally, given that there are advantages and disadvantages to either 
approach, we’re certainly not going to change it during WG last call.

Thanks,

Acee

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr mailto:lsr@ietf.org>>
Cc: 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/

Thanks,
Acee & Chris

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

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

2022-08-21 Thread Ketan Talaulikar

Hi Shraddha,

Thanks for your response. Please check inline below with KT2 for some
clarifications.

We'll work on posting the update once this one remaining discussion point
is closed.


On Mon, Aug 22, 2022 at 9:46 AM Shraddha Hegde  wrote:

> Hi Ketan,
>
>
>
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, August 18, 2022 11:28 PM
> *To:* Shraddha Hegde 
> *Cc:* Yingzhen Qu ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>; lsr ;
> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for
> SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Shraddha,
>
>
>
> Thanks for your detailed review and please check inline below for
> responses.
>
>
>
>
>
> On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde 
> wrote:
>
> Authors,
>
> OSPFv3 extensions for Srv6 is a useful draft and I support progressing
> this draft.
> I have below comments.
>
>
>
>   1. Add a section to describe benefits of defining a new locator LSA
> rather than
>  putting locator sub-TLV in existing LSAs.
>
>
>
> KT> I do not personally see a significant benefit in using a new LSA as
> opposed to re-using existing ones. When this draft was originally proposed,
> we (authors) were not able to use the base extended prefix LSAs due to the
> mandatory requirement for using the base prefix reachability TLVs per
> RFC8362. Hence, we went with the new LSAs so as not to mix up the
> reachabilities and follow RFC8362. However, after further discussions in
> the WG, there were newer methods determined (e.g., the use of LSInfinity as
> a metric for the base prefix reachability TLVs that we are doing for OSPFv3
> IP FlexAlgo). However, by then there were already implementations using the
> new LSAs for OSPFv3 SRvt, so it was decided to continue with the approach
> of using the new LSAs.
>
>
>
>  OK
>
>
>
> 2.
> "The processing of the prefix
>   advertised in the SRv6 Locator TLV, the calculation of its
>   reachability, and the installation in the forwarding plane follows
>   the OSPFv3 [RFC5340] specifications for the respective route types.
>   Locators associated with algorithms 0 and 1 SHOULD be advertised
>   using the respective OSPFv3 Extended LSA types with extended TLVs
>   [RFC8362] so that routers that do not support SRv6 will install a
>   forwarding entry for SRv6 traffic matching those locators.  When
>   operating in Extended LSA sparse-mode [RFC8362], these locators
>   SHOULD be also advertised using the respective legacy OSPFv3 LSAs
>   [RFC5340]."
>
>I suggest to change the SHOULD to MUST
>and always use legacy LSAs/extended LSAs for reachability
>   calculation for algo 0 and algo 1.
>   The current text says use legacy LSAs/extended LSAs if its
> there.
>
>
>
> KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*section-5__;Iw!!NEt6yMaO-gk!F5ePU2u8gidMUa5UIGC_tSJ6PeNxoOhrD6NgqAHhxZ7Pk487kQLvCJuHJdmtzGeVlQJ0aMsTGgoiZbjikKYjlA$>
> ).
>
>
>
>  If we decide to keep congruent with ISIS, that’s fine
>
> I noticed that section corresponding to below is missing in OSPF
>
> “Locators associated with Flexible Algorithms (see Section 4 of
>
>[I-D.ietf-lsr-flex-algo
> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#ref-I-D.ietf-lsr-flex-algo>])
> SHOULD NOT be advertised in Prefix
>
>Reachability TLVs (236 or 237).  Advertising the Flexible Algorithm
>
>locator in regular Prefix Reachability TLV (236 or 237) would make
>
>the forwarding for it to follow algo 0 path.”
>
>
>
> I think this applies to OSPF as well as there is no algo field in the
> legacy or
>
> Extended LSAs.
>

KT2> Ack. Will include that.


>
>
>
>
>
>
>   The locator TLV does not seem to have all the information
> needed in all cases
>   for route calculation. From a quick scan I found below info
> missing in Locator TLV
>
>- NSSA forwarding address
>
>when the locator is exported from another OSPF domain and
> originated as a NSSA type
>   the ability to advertise NSSA fwding address and use it in
> route calc

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

2022-08-21 Thread Shraddha Hegde

Hi Ketan,

Pls see inline..

Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Thursday, August 18, 2022 11:28 PM
To: Shraddha Hegde 
Cc: Yingzhen Qu ; Acee Lindem (acee) 
; lsr ; 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

Hi Shraddha,

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

On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Authors,

OSPFv3 extensions for Srv6 is a useful draft and I support progressing this 
draft.
I have below comments.

  1. Add a section to describe benefits of defining a new locator LSA rather 
than
 putting locator sub-TLV in existing LSAs.

KT> I do not personally see a significant benefit in using a new LSA as opposed 
to re-using existing ones. When this draft was originally proposed, we 
(authors) were not able to use the base extended prefix LSAs due to the 
mandatory requirement for using the base prefix reachability TLVs per RFC8362. 
Hence, we went with the new LSAs so as not to mix up the reachabilities and 
follow RFC8362. However, after further discussions in the WG, there were newer 
methods determined (e.g., the use of LSInfinity as a metric for the base prefix 
reachability TLVs that we are doing for OSPFv3 IP FlexAlgo). However, by then 
there were already implementations using the new LSAs for OSPFv3 SRvt, so it 
was decided to continue with the approach of using the new LSAs.

 OK

2.
"The processing of the prefix
  advertised in the SRv6 Locator TLV, the calculation of its
  reachability, and the installation in the forwarding plane follows
  the OSPFv3 [RFC5340] specifications for the respective route types.
  Locators associated with algorithms 0 and 1 SHOULD be advertised
  using the respective OSPFv3 Extended LSA types with extended TLVs
  [RFC8362] so that routers that do not support SRv6 will install a
  forwarding entry for SRv6 traffic matching those locators.  When
  operating in Extended LSA sparse-mode [RFC8362], these locators
  SHOULD be also advertised using the respective legacy OSPFv3 LSAs
  [RFC5340]."

   I suggest to change the SHOULD to MUST
   and always use legacy LSAs/extended LSAs for reachability
  calculation for algo 0 and algo 1.
  The current text says use legacy LSAs/extended LSAs if its there.

KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*section-5__;Iw!!NEt6yMaO-gk!F5ePU2u8gidMUa5UIGC_tSJ6PeNxoOhrD6NgqAHhxZ7Pk487kQLvCJuHJdmtzGeVlQJ0aMsTGgoiZbjikKYjlA$>).

 If we decide to keep congruent with ISIS, that's fine
I noticed that section corresponding to below is missing in OSPF

"Locators associated with Flexible Algorithms (see Section 4 of

[I-D.ietf-lsr-flex-algo<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#ref-I-D.ietf-lsr-flex-algo>])
 SHOULD NOT be advertised in Prefix
   Reachability TLVs (236 or 237).  Advertising the Flexible Algorithm
   locator in regular Prefix Reachability TLV (236 or 237) would make
   the forwarding for it to follow algo 0 path."

I think this applies to OSPF as well as there is no algo field in the legacy or
Extended LSAs.

  The locator TLV does not seem to have all the information needed 
in all cases
  for route calculation. From a quick scan I found below info 
missing in Locator TLV

   - NSSA forwarding address

   when the locator is exported from another OSPF domain and 
originated as a NSSA type
  the ability to advertise NSSA fwding address and use it in route 
calculation is required

KT> Thanks for catching that. Looks like we've missed the listing of the IPv6 
Forwarding Address and similar sub-TLVs that can be used as a sub-TLV of the 
SRv6 Locator TLV. Will fix that and share the update for review.
 ok

3. If authors agree to change as per comment 2 then metric and route-type 
fields in locator TLV
   for alo 0 and algo 1 must be ignored.

KT> Please see my response to your comment #2.

4. Need to add clarification the intra area prefix LSA corresponding to the 
locator will have the fields
Referenced LS Type, Referenced Link State ID, and Referenced
  Advertising Router

KT> Since we are talking about SRv6 Locators, that are associated with the node 
and not a LAN, I am not sure these fields hold much relevance. Please let me 
know if I am missing something.
 I agree there is no relevance, but its important to specify there is no 
relevance and describe what

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

2022-08-19 Thread Aijun Wang

Hi, Zhibo:

OK.

Regarding to the point #1, it is better to relax the description for more 
broader applications of SRv6 SID information. You can also keep it in the 
current status because it doesn’t not say “MUST only” be included in the 
mentioned TLVs.

Regarding to point #2, using the newly defined LSA may be one more clean way to 
introduce the SRv6 Locator information within the existing OSPF network, or 
else, we must exploit the LSInfinity field, which may introduce more confusions 
when different router interprets its meaning differently. 

Let’s constrain  the LSInfinity within its original purpose.


Aijun Wang
China Telecom

> On Aug 19, 2022, at 18:27, Huzhibo  
> wrote:
> 
> Hi Aijun,
>  
> Thanks for your detailed review and please check inline below for responses.
>  
>  
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
> Sent: Friday, August 19, 2022 5:55 PM
> To: 'Acee Lindem (acee)' ; 'lsr' 
> 
> Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
> draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>  
> Hi, All:
>  I have the following comments for this draft, and would like to support 
> its forwarding when the below concerns are addressed.
> 
> 1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
> advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
>   There are situations that such information can be utilized by the routers 
> within the area, as I presented at the IETF 114 meeting (the draft is pending 
> to be updated).  Then the following sentence:
>“SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
>for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
>specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-
>Router-Link TLV.”
>   
> Should be relaxed as:
>“SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
>for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
>specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
> Neighbor/Link related TLVs.”
>  
> Zhibo> This description does not affect the new TLVs. If a new TLV is added, 
> you can include the sub TLV in the new TLV.
>  
> 2. Support for the “SRv6 Locator TLV” to be included within the existing 
> LSA, rather than to define the new “Locator LSA”.
> Zhibo> The reason for defining new LSAs is to prevent processing errors on 
> nodes that do not support SRv6. For example, ignoring algorithm fields may 
> cause loops.
> Of course, using LSinfinity metric is one way to solve this problem, but the 
> protocol specifies the IGP does not generate the RIB/Fib for LSinfinity 
> Metric prefix.
> The LSinfinity metric does not meet this scenario. In addition, IS-IS also 
> defines a New TOP TLV. The OSPF definition is the same as that of IS-IS.
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
> (acee)
> Sent: Saturday, July 30, 2022 1:17 AM
> To: lsr 
> Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
> draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>  
> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
> extra week is to account for PIST (Post-IETF Stress Syndrome). The 
> corresponding IS-IS draft is already on the RFC Queue and there are 
> implementations.
>  
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>  
>  
> Thanks,
> Acee & Chris
>  
>  
> ___
> 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 Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

2022-08-19 Thread Huzhibo

Hi Aijun,

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

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 19, 2022 5:55 PM
To: 'Acee Lindem (acee)' ; 'lsr' 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi, All:
 I have the following comments for this draft, and would like to support 
its forwarding when the below concerns are addressed.

1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
  There are situations that such information can be utilized by the routers 
within the area, as I presented at the IETF 114 meeting (the draft is pending 
to be updated).  Then the following sentence:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-
   Router-Link TLV.”

Should be relaxed as:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
Neighbor/Link related TLVs.”

Zhibo> This description does not affect the new TLVs. If a new TLV is added, 
you can include the sub TLV in the new TLV.

2. Support for the “SRv6 Locator TLV” to be included within the existing 
LSA, rather than to define the new “Locator LSA”.

Zhibo> The reason for defining new LSAs is to prevent processing errors on 
nodes that do not support SRv6. For example, ignoring algorithm fields may 
cause loops.

Of course, using LSinfinity metric is one way to solve this problem, but the 
protocol specifies the IGP does not generate the RIB/Fib for LSinfinity Metric 
prefix.

The LSinfinity metric does not meet this scenario. In addition, IS-IS also 
defines a New TOP TLV. The OSPF definition is the same as that of IS-IS.

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr mailto:lsr@ietf.org>>
Cc: 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/

Thanks,
Acee & Chris

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

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

2022-08-19 Thread Aijun Wang

Hi, All:

 I have the following comments for this draft, and would like to support 
its forwarding when the below concerns are addressed.

 

1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
  There are situations that such information can be utilized by the routers 
within the area, as I presented at the IETF 114 meeting (the draft is pending 
to be updated).  Then the following sentence:

   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except

   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a

   specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-

   Router-Link TLV.”

   

Should be relaxed as:

   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except

   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a

   specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
Neighbor/Link related TLVs.”

 

 

2. Support for the “SRv6 Locator TLV” to be included within the existing 
LSA, rather than to define the new “Locator LSA”. 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

 

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations. 

 

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ 

 

 

Thanks,

Acee & Chris

 

 

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

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

2022-08-18 Thread Ketan Talaulikar

Hi Shraddha,

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

On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde  wrote:

> Authors,
>
> OSPFv3 extensions for Srv6 is a useful draft and I support progressing
> this draft.
> I have below comments.
>
>
>
>   1. Add a section to describe benefits of defining a new locator LSA
> rather than
>  putting locator sub-TLV in existing LSAs.
>

KT> I do not personally see a significant benefit in using a new LSA as
opposed to re-using existing ones. When this draft was originally proposed,
we (authors) were not able to use the base extended prefix LSAs due to the
mandatory requirement for using the base prefix reachability TLVs per
RFC8362. Hence, we went with the new LSAs so as not to mix up the
reachabilities and follow RFC8362. However, after further discussions in
the WG, there were newer methods determined (e.g., the use of LSInfinity as
a metric for the base prefix reachability TLVs that we are doing for OSPFv3
IP FlexAlgo). However, by then there were already implementations using the
new LSAs for OSPFv3 SRvt, so it was decided to continue with the approach
of using the new LSAs.

> 2.
> "The processing of the prefix
>   advertised in the SRv6 Locator TLV, the calculation of its
>   reachability, and the installation in the forwarding plane follows
>   the OSPFv3 [RFC5340] specifications for the respective route types.
>   Locators associated with algorithms 0 and 1 SHOULD be advertised
>   using the respective OSPFv3 Extended LSA types with extended TLVs
>   [RFC8362] so that routers that do not support SRv6 will install a
>   forwarding entry for SRv6 traffic matching those locators.  When
>   operating in Extended LSA sparse-mode [RFC8362], these locators
>   SHOULD be also advertised using the respective legacy OSPFv3 LSAs
>   [RFC5340]."
>
>I suggest to change the SHOULD to MUST
>and always use legacy LSAs/extended LSAs for reachability
>   calculation for algo 0 and algo 1.
>   The current text says use legacy LSAs/extended LSAs if its
> there.
>

KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5
).

>   The locator TLV does not seem to have all the information
> needed in all cases
>   for route calculation. From a quick scan I found below info
> missing in Locator TLV
>
>- NSSA forwarding address
>
>when the locator is exported from another OSPF domain and
> originated as a NSSA type
>   the ability to advertise NSSA fwding address and use it in
> route calculation is required
>

KT> Thanks for catching that. Looks like we've missed the listing of the
IPv6 Forwarding Address and similar sub-TLVs that can be used as a sub-TLV
of the SRv6 Locator TLV. Will fix that and share the update for review.

>
>
>
> 3. If authors agree to change as per comment 2 then metric and route-type
> fields in locator TLV
>for alo 0 and algo 1 must be ignored.
>

KT> Please see my response to your comment #2.

>
> 4. Need to add clarification the intra area prefix LSA corresponding to
> the locator will have the fields
> Referenced LS Type, Referenced Link State ID, and Referenced
>   Advertising Router
>

KT> Since we are talking about SRv6 Locators, that are associated with the
node and not a LAN, I am not sure these fields hold much relevance. Please
let me know if I am missing something.

Thanks,
Ketan

>
>
> Rgds
> Shraddha
>
>
>
> Juniper Business Use Only
> From: Lsr  On Behalf Of Yingzhen Qu
> Sent: Wednesday, August 17, 2022 5:22 AM
> To: Acee Lindem (acee) 
> Cc: lsr ; draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for
> SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>
> [External Email. Be cautious of content]
>
> I support progressing this draft.
>
> I have the following minor comments for the authors to consider:
>
>
>   *   The title of Section 4 of this draft is "Advertisement of SRH
> Operation Limits", and really it only covers the advertisements of MSDs, so
> may consider to change the title to be consistent with the ISIS SRv6
> extensions draft, "Advertising Maximum SRv6 SID Depths".
>
>   *   The subsections in section 4 are almost identical to the subsections
> in draft-ietf-lsr-isis-srv6-extesions. It's up to the authors and the WG to
> decide whether to keep this duplicate.
>   *   In draft-ietf-lsr-isis-srv6-extensions, "topolo

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

2022-08-18 Thread Shraddha Hegde

Authors,

OSPFv3 extensions for Srv6 is a useful draft and I support progressing this 
draft.
I have below comments.



  1. Add a section to describe benefits of defining a new locator LSA rather 
than
 putting locator sub-TLV in existing LSAs.
2.
"The processing of the prefix
  advertised in the SRv6 Locator TLV, the calculation of its
  reachability, and the installation in the forwarding plane follows
  the OSPFv3 [RFC5340] specifications for the respective route types.
  Locators associated with algorithms 0 and 1 SHOULD be advertised
  using the respective OSPFv3 Extended LSA types with extended TLVs
  [RFC8362] so that routers that do not support SRv6 will install a
  forwarding entry for SRv6 traffic matching those locators.  When
  operating in Extended LSA sparse-mode [RFC8362], these locators
  SHOULD be also advertised using the respective legacy OSPFv3 LSAs
  [RFC5340]."

   I suggest to change the SHOULD to MUST
   and always use legacy LSAs/extended LSAs for reachability
  calculation for algo 0 and algo 1.
  The current text says use legacy LSAs/extended LSAs if its there.
  The locator TLV does not seem to have all the information needed 
in all cases
  for route calculation. From a quick scan I found below info 
missing in Locator TLV

   - NSSA forwarding address

   when the locator is exported from another OSPF domain and 
originated as a NSSA type
  the ability to advertise NSSA fwding address and use it in route 
calculation is required



3. If authors agree to change as per comment 2 then metric and route-type 
fields in locator TLV
   for alo 0 and algo 1 must be ignored.

4. Need to add clarification the intra area prefix LSA corresponding to the 
locator will have the fields
Referenced LS Type, Referenced Link State ID, and Referenced
  Advertising Router


Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Wednesday, August 17, 2022 5:22 AM
To: Acee Lindem (acee) 
Cc: lsr ; draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

I support progressing this draft.

I have the following minor comments for the authors to consider:


  *   The title of Section 4 of this draft is "Advertisement of SRH Operation 
Limits", and really it only covers the advertisements of MSDs, so may consider 
to change the title to be consistent with the ISIS SRv6 extensions draft, 
"Advertising Maximum SRv6 SID Depths".

  *   The subsections in section 4 are almost identical to the subsections in 
draft-ietf-lsr-isis-srv6-extesions. It's up to the authors and the WG to decide 
whether to keep this duplicate.
  *   In draft-ietf-lsr-isis-srv6-extensions, "topology/algorithm" is used, and 
it's not consistently used in this draft. For example, in section 5 the second 
paragraph, only "algorithm" is used, while "topology/algorithm" is used later.

Nits (line numbers are from idnits):

208the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]
SR Algorithm/SR-Algorithm  Please add a "-" to be consistent with RFC 8665.


355The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
"TBD" should be replaced with "42" as in IANA considerations.

Thanks,
Yingzhen


On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>> wrote:

As promised in today's LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.


https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/__;!!NEt6yMaO-gk!DAXEDn6VRnJtBqXHQdE0K6Smc3xswV5wjsQfMVAtSr2slsMp1MgPE3z27tL8M4RBvnlPen-ceWgz0SvcPXaTjCbD$>


Thanks,
Acee & Chris


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!DAXEDn6VRnJtBqXHQdE0K6Smc3xswV5wjsQfMVAtSr2slsMp1MgPE3z27tL8M4RBvnlPen-ceWgz0SvcPTh4ZMqx$>

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

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

2022-08-17 Thread Acee Lindem (acee)

Hi Ketan,

From: Ketan Talaulikar 
Date: Wednesday, August 17, 2022 at 11:35 AM
To: Acee Lindem 
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,

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 PrefixOptions came via RFC8362 and so RFC8666 didn't have to do 
anything about it. Refer 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4

Ok – I thought I remembered the N-Flag but I didn’t look close enough at the 
existing IANA assignments. I agree we can use the add the Anycast Bit to the 
Prefix Options. Although it seems to negate the fact that anycast can be routed 
transparently, there are enough drafts presenting use cases as to why it is 
needed.

Thanks,
Acee

Additionally, we can use the remaining bit available for AC-flag (anycast) 
similar to the ISIS SRv6 spec.

Note that this change would not be backward compatible with the current spec 
since the bit positions are moving.

Looking for feedback/input from the WG on this proposed change.

I think we’d just need to get feedback from Dirk (who made the comment that 
initiated this) and the co-authors. Of course, anyone with know of OSPFv3 SRv6 
can comment.

KT> I did discuss offline with Dirk and we agreed on

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

2022-08-17 Thread Ketan Talaulikar

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.

Thanks,
Ketan


On Wed, Aug 17, 2022 at 8:44 PM Acee Lindem (acee)  wrote:

> Hi Ketan,
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Wednesday, August 17, 2022 at 11:04 AM
> *To: *Acee Lindem 
> *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,
>
>
>
> Please check inline below.
>
>
>
>
>
> On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee)  wrote:
>
> Hi Ketan,
>
>
>
> *From: *Lsr  on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Wednesday, August 17, 2022 at 9:48 AM
> *To: *Acee Lindem 
> *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)
>
>
>
> 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 PrefixOptions came via RFC8362 and so RFC8666 didn't have to
> do anything about it. Refer
> https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4
>
>
>
>
>
> Ok – I thought I remembered the N-Flag but I didn’t look close enough at
> the existing IANA assignments. I agree we can use the add the Anycast Bit
> to the Prefix Options. Although it seems to negate the fact that anycast
> can be routed transparently, there are enough drafts presenting use cases
> as to why it is needed.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
> Additionally, we can use the remaining bit available for AC-flag (anycast)
> similar to the ISIS SRv6 spec.
>
>
>
> Note that this change would not be backward compatible with the current
> spec since the bit positions are moving.
>
>
>
> Looking for feedback/input from the WG on this proposed change.
>
>
>
> I think we’d just need to get feedback from Dirk (who made the comment
> that initiated this) and the co-authors. Of course, anyone with know of
> OSPFv3 SRv6 can comment.
>
>
>
> KT> I did discuss offline with Dirk and we agreed on the necessity for the
> LA and P flags for OSPFv3 SRv6. We have not discussed the approach of using
> PrefixOptions instead of the Flags field though and Dirk is now on PTO. I
> hope others can share their views on the PrefixOptions approach.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> Thanks,
> Acee
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee) 
> wrote:
>
> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
> extra week is to account for PIST (Post-IETF Stress Syndrome). The
> corresponding IS-IS draft is already on the RFC Queue and there are
> implementations.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2022-08-17 Thread Acee Lindem (acee)

Hi Ketan,

From: Ketan Talaulikar 
Date: Wednesday, August 17, 2022 at 11:04 AM
To: Acee Lindem 
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,

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 PrefixOptions came via RFC8362 and so RFC8666 didn't have to do 
anything about it. Refer 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4

Ok – I thought I remembered the N-Flag but I didn’t look close enough at the 
existing IANA assignments. I agree we can use the add the Anycast Bit to the 
Prefix Options. Although it seems to negate the fact that anycast can be routed 
transparently, there are enough drafts presenting use cases as to why it is 
needed.

Thanks,
Acee

Additionally, we can use the remaining bit available for AC-flag (anycast) 
similar to the ISIS SRv6 spec.

Note that this change would not be backward compatible with the current spec 
since the bit positions are moving.

Looking for feedback/input from the WG on this proposed change.

I think we’d just need to get feedback from Dirk (who made the comment that 
initiated this) and the co-authors. Of course, anyone with know of OSPFv3 SRv6 
can comment.

KT> I did discuss offline with Dirk and we agreed on the necessity for the LA 
and P flags for OSPFv3 SRv6. We have not discussed the approach of using 
PrefixOptions instead of the Flags field though and Dirk is now on PTO. I hope 
others can share their views on the PrefixOptions approach.

Thanks,
Ketan

Thanks,
Acee

Thanks,
Ketan

On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/

Thanks,
Acee & Chris

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

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

2022-08-17 Thread Ketan Talaulikar

Hi Acee,

Please check inline below.


On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee)  wrote:

> Hi Ketan,
>
>
>
> *From: *Lsr  on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Wednesday, August 17, 2022 at 9:48 AM
> *To: *Acee Lindem 
> *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)
>
>
>
> 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 PrefixOptions came via RFC8362 and so RFC8666 didn't have to
do anything about it. Refer
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4


>
>
>
> Additionally, we can use the remaining bit available for AC-flag (anycast)
> similar to the ISIS SRv6 spec.
>
>
>
> Note that this change would not be backward compatible with the current
> spec since the bit positions are moving.
>
>
>
> Looking for feedback/input from the WG on this proposed change.
>
>
>
> I think we’d just need to get feedback from Dirk (who made the comment
> that initiated this) and the co-authors. Of course, anyone with know of
> OSPFv3 SRv6 can comment.
>

KT> I did discuss offline with Dirk and we agreed on the necessity for the
LA and P flags for OSPFv3 SRv6. We have not discussed the approach of using
PrefixOptions instead of the Flags field though and Dirk is now on PTO. I
hope others can share their views on the PrefixOptions approach.

Thanks,
Ketan


>
>
> Thanks,
> Acee
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee) 
> wrote:
>
> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
> extra week is to account for PIST (Post-IETF Stress Syndrome). The
> corresponding IS-IS draft is already on the RFC Queue and there are
> implementations.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2022-08-17 Thread Acee Lindem (acee)

Hi Yingzhen,

From: Yingzhen Qu 
Date: Tuesday, August 16, 2022 at 7:52 PM
To: Acee Lindem 
Cc: lsr , "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

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

I support progressing this draft.

I have the following minor comments for the authors to consider:

· The title of Section 4 of this draft is “Advertisement of SRH 
Operation Limits”, and really it only covers the advertisements of MSDs, so may 
consider to change the title to be consistent with the ISIS SRv6 extensions 
draft, "Advertising Maximum SRv6 SID Depths”.
· The subsections in section 4 are almost identical to the subsections 
in draft-ietf-lsr-isis-srv6-extesions. It’s up to the authors and the WG to 
decide whether to keep this duplicate.
I have encouraged LSR authors to allow protocol encoding section to stand on 
their own rather than reference the other document and describe the deltas. In 
some cases, OSPF and IS-IS can share IANA registries for common enumerations. I 
see Ketan replied consistent with this approach.
Thanks,
Acee

· In draft-ietf-lsr-isis-srv6-extensions, “topology/algorithm” is used, 
and it’s not consistently used in this draft. For example, in section 5 the 
second paragraph, only “algorithm” is used, while “topology/algorithm” is used 
later.

Nits (line numbers are from idnits):

208 the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]
SR Algorithm/SR-Algorithm  Please add a “-“ to be consistent with RFC 8665.

355 The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
“TBD” should be replaced with “42” as in IANA considerations.

Thanks,
Yingzhen

On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>> wrote:

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/

Thanks,
Acee & Chris

___
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 Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

2022-08-17 Thread Acee Lindem (acee)

Hi Ketan,

From: Lsr  on behalf of Ketan Talaulikar 

Date: Wednesday, August 17, 2022 at 9:48 AM
To: Acee Lindem 
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)

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

Additionally, we can use the remaining bit available for AC-flag (anycast) 
similar to the ISIS SRv6 spec.

Note that this change would not be backward compatible with the current spec 
since the bit positions are moving.

Looking for feedback/input from the WG on this proposed change.

I think we’d just need to get feedback from Dirk (who made the comment that 
initiated this) and the co-authors. Of course, anyone with know of OSPFv3 SRv6 
can comment.

Thanks,
Acee

Thanks,
Ketan

On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/

Thanks,
Acee & Chris

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

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

2022-08-17 Thread Ketan Talaulikar

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.

Additionally, we can use the remaining bit available for AC-flag (anycast)
similar to the ISIS SRv6 spec.

Note that this change would not be backward compatible with the current
spec since the bit positions are moving.

Looking for feedback/input from the WG on this proposed change.

Thanks,
Ketan

On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee)  wrote:

> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
> extra week is to account for PIST (Post-IETF Stress Syndrome). The
> corresponding IS-IS draft is already on the RFC Queue and there are
> implementations.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2022-08-17 Thread Ketan Talaulikar

Hi Yingzhen,

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

The changes as discussed below will be reflected in the upcoming update of
the draft.


On Wed, Aug 17, 2022 at 5:22 AM Yingzhen Qu  wrote:

> I support progressing this draft.
>
> I have the following minor comments for the authors to consider:
>
>
>- The title of Section 4 of this draft is “Advertisement of SRH
>Operation Limits”, and really it only covers the advertisements of MSDs, so
>may consider to change the title to be consistent with the ISIS SRv6
>extensions draft, "Advertising Maximum SRv6 SID Depths”.
>
> KT> Ack. We'll update the title.


>
>- The subsections in section 4 are almost identical to the subsections
>in draft-ietf-lsr-isis-srv6-extesions. It’s up to the authors and the WG to
>decide whether to keep this duplicate.
>
> KT> The individual version of this draft used to have a pointer to the
ISIS SRv6 spec for this purpose (refer to
https://datatracker.ietf.org/doc/html/draft-li-ospf-ospfv3-srv6-extensions-06#section-4)
and it was later elaborated into the current state based on WG inputs.


>
>- In draft-ietf-lsr-isis-srv6-extensions, “topology/algorithm” is
>used, and it’s not consistently used in this draft. For example, in section
>5 the second paragraph, only “algorithm” is used, while
>“topology/algorithm” is used later.
>
> KT> Removed the reference to "topology" since we don't have MT for OSPFv3
defined as yet.


>
> Nits (line numbers are from idnits):
>
> 208  the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]
>
> SR Algorithm/SR-Algorithm  Please add a “-“ to be consistent with RFC 8665.
>

KT> Ack - will fix.


>
> 355  The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
>
> “TBD” should be replaced with “42” as in IANA considerations.
>

KT> Ack - will fix.

Thanks,
Ketan


>
> Thanks,
> Yingzhen
>
>
> On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) <
> acee=40cisco@dmarc.ietf.org> wrote:
>
> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
> extra week is to account for PIST (Post-IETF Stress Syndrome). The
> corresponding IS-IS draft is already on the RFC Queue and there are
> implementations.
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
> Thanks,
> Acee & Chris
>
>
> ___
> 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 Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

2022-08-16 Thread Yingzhen Qu

I support progressing this draft. 

I have the following minor comments for the authors to consider:

The title of Section 4 of this draft is “Advertisement of SRH Operation 
Limits”, and really it only covers the advertisements of MSDs, so may consider 
to change the title to be consistent with the ISIS SRv6 extensions draft, 
"Advertising Maximum SRv6 SID Depths”.
The subsections in section 4 are almost identical to the subsections in 
draft-ietf-lsr-isis-srv6-extesions. It’s up to the authors and the WG to decide 
whether to keep this duplicate.
In draft-ietf-lsr-isis-srv6-extensions, “topology/algorithm” is used, and it’s 
not consistently used in this draft. For example, in section 5 the second 
paragraph, only “algorithm” is used, while “topology/algorithm” is used later.

Nits (line numbers are from idnits):
208the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]
SR Algorithm/SR-Algorithm  Please add a “-“ to be consistent with RFC 8665.

355The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
“TBD” should be replaced with “42” as in IANA considerations. 

Thanks,
Yingzhen

> On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) 
>  wrote:
> 
> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
> extra week is to account for PIST (Post-IETF Stress Syndrome). The 
> corresponding IS-IS draft is already on the RFC Queue and there are 
> implementations.
>  
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ 
> 
>  
>  
> Thanks,
> Acee & Chris
>  
>  
> ___
> 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 Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

2022-08-16 Thread Chengli (Cheng Li)

I support the publication of the draft. It is happy to see SRv6 basic drafts 
are going to be published step by step, it helps the industry very much.

Respect,
Cheng






From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

2022-08-16 Thread Gengxuesong (Geng Xuesong)

Hi WG,

I’ve read the document and it introduces reasonable OSPFv3 extensions for SRv6 
which is useful for SRv6 deployment.
Support publication.

Best
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

2022-08-12 Thread Gyan Mishra

I support publication of this specification for the SRV6 OSPFV3 extension
as the SRV6 ISIS extension is in RFC queue.

Do we have any implementations of this OSPFv3 extension?

Thanks

Gyan
On Fri, Jul 29, 2022 at 1:17 PM Acee Lindem (acee)  wrote:

> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
> extra week is to account for PIST (Post-IETF Stress Syndrome). The
> corresponding IS-IS draft is already on the RFC Queue and there are
> implementations.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2022-08-12 Thread Susan Hares

Support.

This matches the IS-IS SRv6 extensions, and it is ready to publish.

Sue

From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, August 10, 2022 11:22 AM
To: Acee Lindem (acee) ; lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Support. It provides necessary OSPF extensions for SRv6 which is equivalent to 
the IS-IS SRv6 extensions. Best regards, Jie  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  
‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External 
(jie.dong=40huawei@dmarc.ietf.org<mailto:jie.dong=40huawei@dmarc.ietf.org>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzFkOGQ3Mzg2ZmJiM2MxZGMxY2IwMDhhNDdiMGFkY2UyLzE2NjAxNDQ5NTMuODY=#key=17e9395d4d98e5563eee6102edb1d7c2>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

Support.

It provides necessary OSPF extensions for SRv6 which is equivalent to the IS-IS 
SRv6 extensions.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr mailto:lsr@ietf.org>>
Cc: 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.


https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJw9jksOwjAMBa-CsiY_WkJAQupV3NilBZogJwUE4u6QDdvRvNF7i4Wv4rASYym3fNAaoUBhCBdiNVEZVOKTxhQ0MgxFViSvmWXKt-HeyMx3J-lZKOYpxazFeiUutRep_JbWbL3b243OIzDlLuJrVCHN2qLHXePd0PdNsBhs6I3x0O56Axhoo61zxrbtftso72qVavU8kcIUT8fWjAs8aKqxDmfg8H9bZazyH3y-UtZJew.MEUCIBcYPL58pTdquwXJaOMDsuA8jIURVUBFxfzd0GW4f5LMAiEAwv2AcfKeTRillZpoehOAjVnUJDgTxbDP3Hn4FNQJP_o>


Thanks,
Acee & Chris


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

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

2022-08-12 Thread Huaimo Chen

Hi Everyone,

I read through the document and support its publication.

Best Regards,
Huaimo



From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, July 29, 2022 at 1:18 PM
To: lsr 
Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

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



As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.



https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/





Thanks,

Acee & Chris




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

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

2022-08-12 Thread Acee Lindem (acee)

Speaking as WG member:

I support publication of this draft. I reviewed the draft and my comments have 
been incorporated.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, July 29, 2022 at 1:18 PM
To: lsr 
Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

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

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

2022-08-12 Thread Lizhenbin

Hi All,
I support to publish the draft as the co-author. It has been stable and well 
written.

Best Regards,
Zhenbin (Robin)






李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com

发件人：Acee Lindem (acee) 
收件人：lsr 
抄 送：draft-ietf-lsr-ospfv3-srv6-extensions 

时 间：2022-07-30 01:17:42
主 题：Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

2022-08-10 Thread Dongjie (Jimmy)

Support.

It provides necessary OSPF extensions for SRv6 which is equivalent to the IS-IS 
SRv6 extensions.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

2022-08-09 Thread Huzhibo

I support progressing this draft as a co-author. This draft is a basic protocol 
extension of OSPFv3 for SRv6, which is useful and necessary.

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/

Thanks,
Acee & Chris

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

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

2022-08-08 Thread Les Ginsberg (ginsberg)

I support progressing this draft.
IGP support for SRv6 is clearly needed. We already have IS-IS extensions 
defined and WG work on that draft is already complete.
Having the equivalent functionality defined for OSPFv3 closes an obvious gap.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, July 29, 2022 10:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

2022-07-29 Thread Acee Lindem (acee)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

37 matches

Mail list logo