Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

[Ketan Talaulikar (ketant)]

Hi Jeff,

The version 12 addresses all my comments and thanks for the updates.

Thanks,
Ketan

From: Jeff Tantsura <jefftant.i...@gmail.com>
Sent: 08 May 2018 04:53
To: Ketan Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) 
using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

Hi Ketan,

New version (11) should address all your comments, please check and let me know.
ISIS version is being aligned as we speak.

Many thanks!

Cheers,
Jeff
From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of 
"Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>
Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" <a...@cisco.com<mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) 
using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

Hi Acee,

I have reviewed this draft for OSPF but in the same context also gone over its 
corresponding ISIS draft 
(https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ ) and 
some of the comments apply to both since they are mostly identical in content.

I need to ask the question if it makes sense to merge these drafts into a 
single one to save everyone cycles and ensure consistency in the spirit of LSR ☺

General Qs:
1) There are some differences between the ISIS and OSPF versions of this 
draft. Could I request the authors to please cross-check and fix? The ISIS 
draft does not have some of the issues mentioned below.
2) Do these TLVs apply only when the router is enabled for Segment Routing? 
i.e. they should be originated when SR is enabled on the router and the 
receiver should not expect them when SR is disabled? Or do we foresee MSD to be 
more generic. This aspect needs to be clarified.
3) The allowable values are specified as 0-254 in OSPF draft while ISIS one 
allows 255 as well. The IANA section though says that 255 is reserved.
4) The draft using “sub-type” in some places and “type” in some places. 
This is confusing. The ISIS draft uses “type” everywhere which seems better.
5) Several comments below about the section where OSPF TLVs are defined and 
I would suggest to use similar text as in the ISIS draft.
6) I think it is better that the draft mandates that the  MSD sub-types 
SHOULD be encoded in ascending order? This makes it easier for the 
receiver/consumer to detect absence or removal of a specific sub-type from 
signalling.
7) Reference to RFC4970 should be replaced with RFC7770
8) Both the ISIS and OSPF drafts are asking IANA for creation of MSD type 
registry. Should the creation not be done by only one of them and the other 
points to it?


Sec 1


can be imposed at each node/link on a given SR path



It laso also defines

   the Base MPLS Imposition MSD type.


Sec 1.1.1


   BMI: Base MPLS Imposition is the number of MPLS labels that can be

   imposed inclusive of any all service/transport/special labels

Sec 3


Node MSD is the minimum MSD supported by all the links of the node.



Sub-Type 1 (IANA Section), MSD and the Value field contains maximum

   MSD of the router originating the RI LSA.



Some Qs on Sec 3:
1) In my understanding, the Node MSD is the minimum value of all the Link 
MSDs for the links on that node that are enabled in that specific IGP instance. 
There may be another IGP instance configured on the same node with a different 
set of links and for that instance, the Node MSD may be higher. The same goes 
for links that are not configured/enabled under the specific IGP instance. The 
draft needs to clarify this aspect.
2) The draft needs to specify how many instances of this TLV are allowed in 
the RI LSA and when there are multiple instances in the same or multiple RI LSA 
fragments, then how should the receiver handle or interpret them? E.g. uses the 
minimum of the signalled Node MSD values or uses the first instance of the TLV 
in the lowest fragment, etc. Also, we don’t want multiple instances of the MSD 
TLV to be encoded for different types – all of them must be in a single 
instance of the MSD TLV.

Sec 4


   For OSPFv3, the Link level MSD value is advertised as an optional

   Sub-TLV of the Router-Link E-Router-LSA TLV as defined in

   
[I-D.ietf-ospf-ospfv3-lsa-extend<https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd-10#ref-I-D.ietf-ospf-ospfv3-lsa-extend>],
 and has value of TBD3.


   Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD

   of the link router originating the corresponding LSA as specified for

   OSPFv2 and OSPFv3.

Some Qs on Sec 4:
1) The draft needs to specify how many instances of this TLV are

Re: [Lsr] Working Group Last Call on "Signaling MSD (Maximum SID Depth) using OSPF"

[Ketan Talaulikar (ketant)]

Hi All,

I support the further progression of this document. We have implementations of 
the same as well.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 10 May 2018 20:50
To: lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call on "Signaling MSD (Maximum SID 
Depth) using OSPF"

All,

Note that a new version,  -12, was posted today.

Thanks,
Acee

From: Lsr > on behalf of Acee 
Lindem >
Date: Tuesday, May 8, 2018 at 11:48 AM
To: "lsr@ietf.org" >
Subject: [Lsr] Working Group Last Call on "Signaling MSD (Maximum SID Depth) 
using OSPF"

We’ve had consensus on the scope and definition of MSD since the Chicago IETF. 
Since that time, this document has evolved and been improved. It is now ready 
for Working Group Last Call. Please post your objections or support before 
12:00 AM on Wednesday, May 23rd, 2018. For your convenience, here is a URL 
link: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/

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

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

[Ketan Talaulikar (ketant)]

Support publication for this update as it fixes an erroneous encoding 
description in RFC7810.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 23 May 2018 20:59
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

Hi Folks,

We're starting a 2 week WG Last Call on

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/

Please raise any objections or comments before Jun 6th, 2018.

Thanks,
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] OSPF LLS Extensions for Local Interface ID Advertisement - draft-ietf-ospf-lls-interface-id-02

[Ketan Talaulikar (ketant)]

Hello Acee/All,

I am not aware of any IPR that applies to this draft.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 18 June 2018 20:55
To: lsr@ietf.org; draft-ietf-ospf-lls-interface...@ietf.orig
Subject: [Lsr] OSPF LLS Extensions for Local Interface ID Advertisement - 
draft-ietf-ospf-lls-interface-id-02

Authors,  LSR WG,

This mail is to start the Working Group Last Call IPR poll on the subject 
document.

Are you aware of any IPR that applies to draft-ietf-ospf-lls-interface-id?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are currently no IPR disclosures against draft-ietf-ospf-lls-interface-id.

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing list. The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee

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

Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

[Ketan Talaulikar (ketant)]

Hi Gunter,

In that case, I concur with you that option (2) is better than the others. My 
only difference in opinion is that ERLD not have its own separate TLV but 
instead get advertised as a new MSD sub-type - it is just a different encoding.

Thanks,
Ketan

-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp)  
Sent: 13 June 2018 13:55
To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; 
spr...@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic 
motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is 
available, then ELC can be implicitly assumed. No pragmatic reason to signal 
separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both 
>IGP and BGP-LS encoding seems to make little sense and only bring confusion 
>(router/controller implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive 
confusion)
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of 
ELC TLV compared to option (2))
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more 
complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators
* most simple solution for implementers (routers and controller)
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-Original Message-----
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability 
which is advertised differently than ERLD which is a limit. Are you saying that 
ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in 
the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. 
This way we have the flexibility of signalling ERLD both per node and per 
ingress link/LC level.

Thanks,
Ketan

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: 12 June 2018 19:28
To: i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is 
signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK 
ERLD is not of any value at all, is that a correct assumption?)

G/


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-annou...@ietf.org
Cc: i...@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Signalling ERLD using BGP-LS
Authors : Gunter Van de Velde
  Wim Henderickx
  Matthew Bocci
  Keyur Patel
Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
Pages   : 6
Date: 2018-06-12

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readable Label Depth" from a node to a
   centralised controller (PCE/SDN).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02


Please note that it may take 

Re: [Lsr] IGP TE Metric Extensions

[Ketan Talaulikar (ketant)]

Hi Muthu,

These are implementation specific aspects and I am not sure if this is 
something that the draft should be getting into.

Thanks,
Ketan

From: Muthu Arul Mozhi Perumal 
Sent: 05 June 2018 17:19
To: Ketan Talaulikar (ketant) 
Cc: Stefano Previdi (IETF) ; lsr@ietf.org; Jeff Tantsura 

Subject: Re: [Lsr] IGP TE Metric Extensions

Sounds reasonable to me..

Adding a clarification note in the draft would be useful, IMHO.

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Muthu,

The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP 
protocol operation and stability though it is not an integral part of the IGP 
protocol machinery. This functionality in a system, whether achieved in the 
IGP/measurement/some-other module, is an implementation specific aspect.

To answer your question, these aspects may be implemented outside the core IGP 
module and the IGPs simply flood these while satisfying the aspects specified 
in the document.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Muthu Arul Mozhi Perumal
Sent: 05 June 2018 16:42
To: Stefano Previdi (IETF) mailto:s...@previdi.net>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Subject: Re: [Lsr] IGP TE Metric Extensions


​Please see inline..​

On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) 
mailto:s...@previdi.net>> wrote:

On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>> wrote:
Thanks, Jeff. Would be good to have this clarified in
​​
draft-ginsberg-isis-rfc7810bis. My original message seems to have been stripped 
off, so including it again for the lsr list..

​Both RFC 7810 and RFC 7471 say that:

   The measurement interval, any filter coefficients, and any
   advertisement intervals MUST be configurable per sub-TLV.

   Additionally, the default measurement interval for all sub-TLVs
   SHOULD be 30 seconds.

However, both RFCs initially say that they only describe mechanisms for 
disseminating performance information and methods of measurements is outside 
their scope.

Moreover, for a first time reader, it seems to suggest that the measurement 
interval and filter coefficient must be supported and configurable under the 
IGP.


No. This is not suggested in any form.
It is clearly indicated that the draft does not deal with measurements which 
means no recommendation is made.


In a system supporting multiple IGPs, I would expect that they be implemented 
outside the IGP and the IGPs just disseminate the information provided to them.

Thoughts, especially from an implementation standpoint?


Again, the draft is only about dissemination, not measurements..

​How is the measurement interval and filter coefficients described in the draft 
related to dissemination?​

​   The measurement interval, any filter coefficients, and any
   advertisement intervals MUST be configurable per sub-TLV.

   Additionally, the default measurement interval for all sub-TLVs
   SHOULD be 30 seconds.​

If your question is related to configuration and implementation of 
measurements, well it will not be addressed by this draft.

We intentionally left out this part that does not belong to the igp protocol 
machinery.

​Which of the functionalities described in sections 5, 6, 7 of the draft belong 
to the IGP protocol machinery?

Regards,
Muthu


s.



Regards.
Muthu

On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Muthu,

LSR would be a more suitable list to post to, CCed.

Regards,
Jeff

> On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal 
> mailto:muthu.a...@gmail.com>> wrote:
>
> Muthu

___
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] IGP TE Metric Extensions

[Ketan Talaulikar (ketant)]

Hi Muthu,

The sections 5,6,7 specify the required aspects that an implementation needs to 
take care of (with all its normative language) - it specifies the “WHAT” part.

Your questions were related to the “WHERE” and “HOW” parts for the same (e.g. 
when you asked “configurable under IGP” and “outside the IGP” and so on) and 
these are implementation specific aspects which IMHO do not necessarily belong 
to this document.

Hope that clarifies.

I am aware of an implementation that does support certain aspects from section 
5,6,7.

Thanks,
Ketan

From: Muthu Arul Mozhi Perumal 
Sent: 05 June 2018 17:52
To: Ketan Talaulikar (ketant) 
Cc: Stefano Previdi (IETF) ; lsr@ietf.org; Jeff Tantsura 

Subject: Re: [Lsr] IGP TE Metric Extensions

If these are only implementation specific aspects and shouldn't get into the 
draft, what is the point of sections 5,6,7? Why would it hurt to say what is 
generally expected to be part of the protocol machinery and what is not?

BTW, any known implementation for RFC 7810, also supporting sections 5,6,7?

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:33 PM, Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Muthu,

These are implementation specific aspects and I am not sure if this is 
something that the draft should be getting into.

Thanks,
Ketan

From: Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>>
Sent: 05 June 2018 17:19
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Stefano Previdi (IETF) mailto:s...@previdi.net>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>

Subject: Re: [Lsr] IGP TE Metric Extensions

Sounds reasonable to me..

Adding a clarification note in the draft would be useful, IMHO.

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Muthu,

The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP 
protocol operation and stability though it is not an integral part of the IGP 
protocol machinery. This functionality in a system, whether achieved in the 
IGP/measurement/some-other module, is an implementation specific aspect.

To answer your question, these aspects may be implemented outside the core IGP 
module and the IGPs simply flood these while satisfying the aspects specified 
in the document.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Muthu Arul Mozhi Perumal
Sent: 05 June 2018 16:42
To: Stefano Previdi (IETF) mailto:s...@previdi.net>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Subject: Re: [Lsr] IGP TE Metric Extensions


​Please see inline..​

On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) 
mailto:s...@previdi.net>> wrote:

On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>> wrote:
Thanks, Jeff. Would be good to have this clarified in
​​
draft-ginsberg-isis-rfc7810bis. My original message seems to have been stripped 
off, so including it again for the lsr list..

​Both RFC 7810 and RFC 7471 say that:

   The measurement interval, any filter coefficients, and any
   advertisement intervals MUST be configurable per sub-TLV.

   Additionally, the default measurement interval for all sub-TLVs
   SHOULD be 30 seconds.

However, both RFCs initially say that they only describe mechanisms for 
disseminating performance information and methods of measurements is outside 
their scope.

Moreover, for a first time reader, it seems to suggest that the measurement 
interval and filter coefficient must be supported and configurable under the 
IGP.


No. This is not suggested in any form.
It is clearly indicated that the draft does not deal with measurements which 
means no recommendation is made.


In a system supporting multiple IGPs, I would expect that they be implemented 
outside the IGP and the IGPs just disseminate the information provided to them.

Thoughts, especially from an implementation standpoint?


Again, the draft is only about dissemination, not measurements..

​How is the measurement interval and filter coefficients described in the draft 
related to dissemination?​

​   The measurement interval, any filter coefficients, and any
   advertisement intervals MUST be configurable per sub-TLV.

   Additionally, the default measurement interval for all sub-TLVs
   SHOULD be 30 seconds.​

If your question is related to configuration and implementation of 
measurements, well it will not be addressed by this draft.

We intentionally left out this part that does not belong to the igp protocol 
machinery.

​Which of the functionalities described in sections 5, 6, 7 of the draft belong 
to the IGP protocol machinery?

Regards,
Muthu


s.



Regards.
Muthu

On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Muthu,

LSR would be a more suitable list to post to, CCed.

Regards,
Jeff

Re: [Lsr] Working Group Last Call for OSPF LLS Extensions for Local Interface ID Advertisement - draft-ietf-ospf-lls-interface-id-02

[Ketan Talaulikar (ketant)]

Support as a co-author

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 18 June 2018 21:37
To: lsr@ietf.org
Subject: [Lsr] Working Group Last Call for OSPF LLS Extensions for Local 
Interface ID Advertisement - draft-ietf-ospf-lls-interface-id-02

This begins an LSR WG last call for the subject draft. Please send your
comments to this list prior to 12:00 AM GMT, July 3rd, 2018.

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

Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

[Ketan Talaulikar (ketant)]

Hi Uma,

Please check inline below.

Thanks,
Ketan

-Original Message-
From: Uma Chunduri  
Sent: 17 July 2018 08:57
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Cc: spr...@ietf.org
Subject: RE: Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Ketan,


In-line [Uma]:
--
Uma C.

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Tuesday, July 17, 2018 7:13 AM
To: Uma Chunduri ; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Uma,

I would like share more context on the concerns that I raised on this proposal 
in LSR WG yesterday where we could not complete our discussion on the mike due 
to time constraints.

IGPs were originally invented for topology computation and then route 
programming based on the SPT computed. We've extended IGPs to carry/flood 
information and this includes information that were meant for various 
applications. IGPs always do distribute topology computation - that is the core 
principle.

The PPR proposal takes IGPs into the area of flooding p2p paths and then 
setting up forwarding state along the path - essentially introducing path 
provisioning capabilities into it. Essentially adding a new functionality that 
is NOT distributed topology computation.

For clarity, I could summarize the PPR as follows (please correct if wrong):
- Someone (head-end or controller) computes a SR Path which is expressed as a 
SID List (it's a list of EROs just like in RSVP-TE - loose or strict)
- The head-end floods this SR Path (and its EROs) into the IGP domain so all 
routers in the area get the P2P paths computed by all head-ends
- Each router then must look at every such SR Path flooded by every router and 
examine if it is part of the ERO list; if so then it needs to program the 
forwarding state for that PPR id (aka label)
- The headend can then just look at this like a "tunnel" and do something like 
IGP shortcut to the destination behind it

This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p 
path state pervasively. Consider the kind of flooding scale and challenges when 
all these SR Paths go to every router irrespective of whether they need/use it. 
Then on top of that, we are proposing IGPs to program a local cross-connect if 
they are on that SR Path. My question is, why not just use RSVP-TE in this 
case? RSVP-TE does signalling but it does it only on the nodes that matter for 
a specific LSP. 

[Uma]:  This helps in deployments, who is seeking source routing paradigm, but 
SID stack on the packet is unsustainable. This statement is applicable for both 
MPLS and IPv6 case. 
[KT] Could we look at why the SID stack is getting "unsustainable" in the first 
place?

 Coming to the EROs in IGP - it was there in SR drafts, 
including as working group draft for 3 years.  But what completely lacked was 
how to use those.
[KT] Right and I never thought/realized that this was the purpose of those 
EROs. I repeat the scale challenge and that you are proposing to re-purpose 
IGPs for programming MPLS cross-connects for hop-by-hop LSP setup. This is my 
concern.

 There are significant differences in the format and importantly usage to solve 
various issues including hardware 
Compatibilities of various line cards (and hence available 
paths), MTU and line rate issues. I don't think you can use RSVP-TE to solve 
these SR issues.

This is called SR but it introduces a forwarding state on each of the hops 
(i.e. the PPR label cross-connect) - something different from SR architecture. 

[Uma]:  You already introduced per path state in various cases (binding sids to 
local policy, flex-algo).  This has been discussed lately as part of 
re-chartering discussion. 
 This thread discusses that in detail and I fully concur what 
Dave said here 
https://www.ietf.org/mail-archive/web/spring/current/msg03794.html 
[KT] Dave's argument was in multicast context while he was giving the p2p 
example perhaps as a worst case theoretical example. IMHO we should not look at 
such worst case scenarios. To me, this is a hybrid proposal to bring a hop by 
hop path (which is why the SID stack is so huge) like in RSVP-TE into an SR 
network and then try to figure out a way to do this in IGPs. You can feel free 
to disagree :-)

Thanks,
Ketan


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

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

[Ketan Talaulikar (ketant)]

Hi All,

I was reviewing this draft as the Shepherd. It is a fairly simple and 
straightforward bis update to RFC7810 to fix an encoding error.

There is one point that I would like the authors and WG to consider. 

The draft in the appendix talks about two interpretations of the erroneous 
sub-TLVs and from the conversation on the list I get the impression that there 
are at least two implementations out there which did different interpretations. 
Do we want to consider putting in a suggestion (i.e. not normative perhaps) 
that implementations updated to this specifications accept the sub-TLV with the 
Reserved field included and size 5? So they don't consider such an encoding as 
error or malformed on reception?

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 18 June 2018 17:38
To: Les Ginsberg (ginsberg) ; Christian Hopps 
; lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

Hi Les, 
Yes - the Working Group Last call has completed. We'll find a shepherd and 
request publication.
Thanks,
Acee 

On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)"  wrote:

WG chairs -

Can we consider WG last call completed? (It has been more than 3 weeks...)

Would really like to get this small but important correction published ASAP

___
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] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

[Ketan Talaulikar (ketant)]

Hi Les,

This sounds good. I would suggest being liberal in receive (i.e. accept and 
interpret the incorrect encoding) and there is no need to send that erroneous 
encoding.

Thanks,
Ketan

-Original Message-
From: Les Ginsberg (ginsberg) 
Sent: 17 July 2018 13:30
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; Christian Hopps ; lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

Ketan -

Thanx for taking on the role of shepherd.

I am attaching some proposed diffs which I think addresses your concern.
Let me know if this suffices and we can publish an update.

   Les


> -Original Message-
> From: Ketan Talaulikar (ketant)
> Sent: Tuesday, July 17, 2018 6:55 AM
> To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) 
> ; Christian Hopps ; 
> lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
> 
> Hi All,
> 
> I was reviewing this draft as the Shepherd. It is a fairly simple and 
> straightforward bis update to RFC7810 to fix an encoding error.
> 
> There is one point that I would like the authors and WG to consider.
> 
> The draft in the appendix talks about two interpretations of the 
> erroneous sub- TLVs and from the conversation on the list I get the 
> impression that there are at least two implementations out there which 
> did different interpretations. Do we want to consider putting in a 
> suggestion (i.e. not normative perhaps) that implementations updated 
> to this specifications accept the sub-TLV with the Reserved field 
> included and size 5? So they don't consider such an encoding as error or 
> malformed on reception?
> 
> Thanks,
> Ketan
> 
> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: 18 June 2018 17:38
> To: Les Ginsberg (ginsberg) ; Christian Hopps 
> ; lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
> 
> Hi Les,
> Yes - the Working Group Last call has completed. We'll find a shepherd 
> and request publication.
> Thanks,
> Acee
> 
> On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)"  wrote:
> 
> WG chairs -
> 
> Can we consider WG last call completed? (It has been more than 3 
> weeks...)
> 
> Would really like to get this small but important correction 
> published ASAP
> 
> ___
> 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] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Ketan Talaulikar (ketant)]

Hi Aijun,

Your draft introduces the Source Router ID which is, by itself, an useful 
protocol extension. However, the use-case on inter-as topology retrieval has 
issues which has been shared by many of us at the mike, offline and on the list.

Could you consider de-coupling the two?

Also, if the proposal for learning inter-AS as described by you works for your 
own specific network design (and you don't think any of the points made affect 
that decision), then please go ahead. However, I do not see the point of trying 
to get that as an IETF document?

Thanks,
Ketan

-Original Message-
From: Peter Psenak (ppsenak) 
Sent: 24 July 2018 04:22
To: Aijun Wang ; 'Rob Shakir' 
Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; Ketan 
Talaulikar (ketant) ; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology 
retrieval

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> _Hi, Peter:_
>
> For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  
> Describing point-to-point interfaces)  
> <https://tools.ietf.org/html/rfc2328#page-130>, the router LSA will include 
> two links description for each interface, within which the “type 3 link”(stub 
> network) will describe the subnet mask of the point-to-point interface.
>
> For broadcast/NBMA interface, the DR will be elected and it will 
> generate the network LSA which will include also the subnet mask of 
> the connected interface.
>
> For unnumbered and virtual link, if you consider we should include 
> them also for all possible scenarios even if we seldom use them in 
> large network, we can consider expand the summary LSA to cover it, as 
> done by this draft.

there is no way to address unnumbered p2p case your way, because there is no 
Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you several 
examples where your proposal does not work.

thanks,
Peter

>
> For Anycast prefixes situation that you described(although we seldom 
> plan our network in such way), the PCE controller will not deduce the 
> wrong information from the reported information--Different router 
> advertise the same prefix, why can’t they be connected in logically?
>
> On summary, the ABR can know and report the originator of the 
> connected interface’s prefixes, and also the connected information for 
> the unnumbered/virtual link from the traditional router LSA/network 
> LSA message, thus can transfer them to the router that run BGP-LS, 
> then to the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology 
> and has more flexibility to control the topology export as described 
> in RFC
> 7752 <https://tools.ietf.org/html/rfc7752#section-1>.
>
> Solution 1) that you proposed is possible, but we will not run two 
> different methods to get the topology.
>
> Solution 2) is also one possible deployment, but it eliminates the 
> advantage of the BGP-LS, in which it needs several interaction points 
> with the underlay network. and such deployment is not belong to 
> redundancy category as information got from different areaes are different.
>
> Solution 3)--Streaming telemetry technology should be used mainly for 
> the monitor of network devices, it requires the PCE controller to 
> contact with every router in the network, is also not the optimal 
> solution when compared with BGP-LS.
>
> We can update the current draft to include all possible scenarios that 
> we are not aiming at beginning for integrity consideration. The 
> proposed extension does not add to complexity of IGP. What we 
> discussed here is the complexity of IGP protocol itself.
>
> Best Regards.
>
> Aijun Wang
>
> Network R and Operation Support Department
>
> China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
>
> *发件人:*Rob Shakir [mailto:r...@rob.sh]
> *发送时间:*2018年7月24日7:04
> *收件人:*Peter Psenak
> *抄送:*Dongjie (Jimmy); cho...@chopps.org; Ketan Talaulikar (ketant); 
> Aijun Wang; lsr@ietf.org; Acee Lindem (acee)
> *主题:*Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area 
> topology retrieval
>
> +1 to Peter. We should not define fragile solutions within the IETF.
>
> There are also a multitude of other solutions here already:
>
> 1) IGP adjacency with one router in each area (at a minimum - probably 
> two for a robust system) over a tunnel. Deployed in many networks for 
> years.
> 2) BGP-LS to one router (ditto robustness comment) in each area.
> 3) streaming telemetry of the LSDB contents via gNMI.
>
> All these solutions exist in shippin

[Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

[Ketan Talaulikar (ketant)]

Hi Uma,

I would like share more context on the concerns that I raised on this proposal 
in LSR WG yesterday where we could not complete our discussion on the mike due 
to time constraints.

IGPs were originally invented for topology computation and then route 
programming based on the SPT computed. We've extended IGPs to carry/flood 
information and this includes information that were meant for various 
applications. IGPs always do distribute topology computation - that is the core 
principle.

The PPR proposal takes IGPs into the area of flooding p2p paths and then 
setting up forwarding state along the path - essentially introducing path 
provisioning capabilities into it. Essentially adding a new functionality that 
is NOT distributed topology computation.

For clarity, I could summarize the PPR as follows (please correct if wrong):
- Someone (head-end or controller) computes a SR Path which is expressed as a 
SID List (it's a list of EROs just like in RSVP-TE - loose or strict)
- The head-end floods this SR Path (and its EROs) into the IGP domain so all 
routers in the area get the P2P paths computed by all head-ends
- Each router then must look at every such SR Path flooded by every router and 
examine if it is part of the ERO list; if so then it needs to program the 
forwarding state for that PPR id (aka label)
- The headend can then just look at this like a "tunnel" and do something like 
IGP shortcut to the destination behind it

This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p 
path state pervasively. Consider the kind of flooding scale and challenges when 
all these SR Paths go to every router irrespective of whether they need/use it. 
Then on top of that, we are proposing IGPs to program a local cross-connect if 
they are on that SR Path.

My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling 
but it does it only on the nodes that matter for a specific LSP. 

This is called SR but it introduces a forwarding state on each of the hops 
(i.e. the PPR label cross-connect) - something different from SR architecture. 
Including SPRING group as well for the review of this proposed SR solution.

Seems like a mishmash of SR and RSVP-TE to me and I am concerned about where 
this takes IGPs.

Thanks,
Ketan

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

Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

[Ketan Talaulikar (ketant)]

Hi Xiaohu,

The IGP drafts define MSD as a framework that enable advertisements for various 
type of SID limits – starting with the Base MSD Type – 1. You are referring to 
this generic construct of MSD in the text you quote below. It is, however, the 
Base MSD (type 1) which is aligned with the definition in PCEP-SR.

IMHO the PCEP-SR draft definition should be updated to refer to this base MSD 
type.

Thanks,
Ketan

From: mpls  On Behalf Of ???(??)
Sent: 06 July 2018 06:55
To: Jeff Tantsura ; stephane.litkowski 
; m...@ietf.org
Cc: lsr@ietf.org; p...@ietf.org
Subject: Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi Jeff,

Thanks for your clarification. IMHO, no matter the MSD information is provided 
by whatever protocol, the semantics of the MSD itself should be unified in the 
IETF community. Otherwise, it would introduce unnecessary confusion to 
implementors and operators.

It said in the OSPF-MSD draft：
"

   MSD: Maximum SID Depth - the number of SIDs a node or one of its

   links can support"



What does the "support" exactly mean? It seems at least to me a little bit 
ambiguous compared to the MSD concept as defined in the PCEP-SR draft.



Best regards,

Xiaohu




--
From:Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Send Time:2018年7月6日(星期五) 07:48
To:stephane.litkowski 
mailto:stephane.litkow...@orange.com>>; 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>; 
m...@ietf.org mailto:m...@ietf.org>>
Cc:lsr@ietf.org mailto:lsr@ietf.org>>; 
p...@ietf.org mailto:p...@ietf.org>>
Subject:Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi,

Please see inline (MSD section).
Hope this clarifies, thanks!

Cheers,
Jeff



[jeff] both IGP drafts have identical description of the BMI-MSD:
“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”
PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).
However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though.


3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "

The "Maximum SID Depth" (1

   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in the context of this document) that a PCC is capable of

   imposing on a packet.



In the IGP-MSD draft, it said "

MSD of type 1 (IANA Registry), called Base MSD is used to signal the

   total number of SIDs a node is capable of imposing, to be used by a

   path computation element/controller.  "



If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?

[SLI] Today, the two IGP drafts does not seem to agree on the definition

ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”

OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:

“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not 

Re: [Lsr] Implementations of draft-ietf-ospf-link-overload

[Ketan Talaulikar (ketant)]

Hi Alvaro/All,

I am not aware of an implementation of this draft that uses the proposed BGP-LS 
TLV. So there is no issue with using the suggested value of 1121 (or any other 
available).

Thanks,
Ketan

From: Lsr  On Behalf Of Alvaro Retana
Sent: 07 April 2018 00:19
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; draft-ietf-ospf-link-overl...@ietf.org; Acee Lindem 
(acee) 
Subject: [Lsr] Implementations of draft-ietf-ospf-link-overload

Dear lsr WG:

draft-ietf-ospf-link-overload [1] defines a new BGP-LS Graceful-Link-Shutdown 
TLV.  When an early allocation was requested, it was mistakenly requested from 
the "BGP-LS NLRI-Types" registry [2], not from the "BGP-LS Node Descriptor, 
Link Descriptor, Prefix Descriptor, and Attribute TLVs” registry [3].  IANA 
allocated a value according to the request: 1101.

The mistake wasn't noticed until the document was in IESG Evaluation -- we are 
in the process of correcting it.  However, the 1101 code point is already 
allocated [*] in the "BGP-LS Node Descriptor, Link Descriptor, Prefix 
Descriptor, and Attribute TLVs” registry, so a different value is needed - the 
current suggested value is 1121.

Are there implementations of draft-ietf-ospf-link-overload with the 1101 code 
point?  Are there deployments of those implementations?  What will be the 
impact of changing the value to 1121?

Thanks!

Alvaro.

[*] The 1101 code point in the "BGP-LS Node Descriptor, Link Descriptor, Prefix 
Descriptor, and Attribute TLVs” registry corresponds to the Peer-Node-SID, an 
early allocation made to draft-ietf-idr-bgpls-segment-routing-epe [4], which 
says that "several early implementations exist".

[1] https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
[2] 
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#nlri-types
[3] 
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#node-descriptor-link-descriptor-prefix-descriptor-attribute-tlv
[4] https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/


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

Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

[Ketan Talaulikar (ketant)]

Hi Aijun,

You say that certain parts of sections 3 (Procedures) are unnecessary and at 
the same time you ask for “some clarification” and for “error prone” TLV 
definitions.

I do not anymore follow your point or what is it that you want updated in 
draft-ietf-idr-bgp-ls-segment-routing-ext.

Thanks,
Ketan

From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: 10 April 2018 13:46
To: Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: 'Jeffrey Haas' <jh...@pfrc.org>; lsr@ietf.org; i...@ietf.org
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi, Ketan:

I read through the section that you provided at 
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-3,
 and think 3/4 parts of them are unnecessary because the contents of 3.1,3.2 
and 3.3 has been mentioned at the corresponding TLV definition parts. Only 3.4 
part is necessary because it mentions the composite usage of two TLVs and can’t 
fit in any previous TLV definition.

My suggestion is that we add some clarification under the error-prone TLV 
definition respectively, to let the vendor refer them clearly when implementing 
the BGP-LS protocol.

ISIS/OSPF/OSPFv3/BGP-LS are different protocols in mainly the mechanism to 
transfer/digest the message, not the extensible TLVs definition, especially for 
the same purpose TLVs. There are some reasons that need to keep the definition 
compact/different, but beyond that, we should align them as same as possible to 
eliminate the error arose from inter-operation activities among different 
vendor or between device vendor and the SDN controller.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
发送时间: 2018年4月9日 16:45
收件人: Aijun Wang
抄送: 'Jeffrey Haas'; lsr@ietf.org<mailto:lsr@ietf.org>; 
i...@ietf.org<mailto:i...@ietf.org>
主题: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi Aijun,

As responded previously and also clarified by few others, the 3 IGP protocols 
(ISIS, OSPFv2 and OSPFv3) and BGP-LS are different protocols. Their encodings 
need not be identical. However, their semantics generally are so when it comes 
mapping them into BGP-LS.

At this stage, given the advance state of implementations and deployments for 
all these IGP and BGP-LS drafts involved, I don’t think we can undertake such 
“cosmetic” changes.

However, the draft-ietf-idr-bgp-ls-segment-routing-ext-04 is in WGLC and I can 
definitely take your feedback for any updates in the text or clarifications 
necessary in this document. Note that the procedures for the TLVs where 
mappings were non-trivial are described in the Procedures section - 
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-3
 . The TLVs you mention below are very trivial and the mapping from IGPs to 
BGP-LS is straightforward so the authors believe the explanation in Section 2 
where each TLV field is described is sufficient.

In the end, I am not sure if any of this helps/addresses implementation defects 
(where the reserved field itself was skipped from the BGP-LS TLV) that you have 
identified in your deployment on the producer side.

Thanks,
Ketan

From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: 08 April 2018 07:02
To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>
Cc: 'Jeffrey Haas' <jh...@pfrc.org<mailto:jh...@pfrc.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi, Ketan:

I think there is another reason that causes this semantic error-that is 
there is many similarities for the definition of “Adj-SID Sub-TLV” for ISIS and 
OSPFv3 in the following draft:
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-11#section-6.1
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-15#section-2.2.1

but there is no any description in the relevant paragraph to  distinguish them 
in BGP-LS document.
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-2.2.1


Ketan explained that “ISIS uses 1 byte for type/length and has LSP space 
constraints which you would notice in  the protocol encodings. OSPF doesn’t 
have the same challenge and you would notice how its TLVs tend to be aligned. 
BGP-LS is somewhat similar to OSPF from these size constraints perspective.” 
But when I compared another TLV definition “SRMS Preference TLV” in randomly, I 
found the definition in BGP-LS is different from that both in ISIS 

Re: [Lsr] Flex Algorithms Drafts

[Ketan Talaulikar (ketant)]

Hi Acee,

I don't see a problem with the merge for ISIS and OSPF specs in a single 
document in this case. Authors are mostly identical and even though the ISIS 
spec was published earlier, the OSPF spec is fully in sync and leverages all 
those comments.

A lot of the text applies to both protocols and we would just need to organize 
the protocol specific parts in the document.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Peter Psenak (ppsenak)
Sent: 12 April 2018 13:05
To: Acee Lindem (acee) ; lsr@ietf.org
Cc: draft-hegdeppsenak-isis-sr-flex-a...@ietf.org
Subject: Re: [Lsr] Flex Algorithms Drafts

Hi Acee,

On 11/04/18 22:36 , Acee Lindem (acee) wrote:
> In preparation for WG adoption and IANA early code point allocation, I 
> suggest that we rename the “Flexible Algorithm Definition TLV Metric 
> Registry” to the “Flexible Algorithm Definition TLV Metric Type Registry” to 
> avoid confusion as to whether we are defining the actual metrics here. I know 
> that in the contexts of the drafts, it is clear but the registries are going 
> to be on their own. Additionally, while protocol TLV types should not be 
> shared between protocols, it seems this registry could be common and placed 
> in our "Interior Gateway Protocol (IGP) Parameters" registry.

sure I can make that change.

>
> Finally, the OSPF version has a typo in section 8.2. The last two types 
> should be 2 and 3.

right, will fix it.
>
> o  0 - Reserved
>
> o  1 - Flexible Algorithm Exclude Admin Group Sub-TLV
>
> o  1 - Flexible Algorithm Include-Any Admin Group Sub-TLV
>
> o  1 - Flexible Algorithm Exclude-All Group Sub-TLV
>
> Also, how so the authors feel about combining the drafts? I know the IS-IS 
> version has had more discussion and wouldn't want to hold it up if there is a 
> possibility. I don't feel strongly one way or another.

I'm fine both ways.

thanks,
Peter

>
> Thanks,
> Acee
>

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

Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

[Ketan Talaulikar (ketant)]

Hi Aijun,

As responded previously and also clarified by few others, the 3 IGP protocols 
(ISIS, OSPFv2 and OSPFv3) and BGP-LS are different protocols. Their encodings 
need not be identical. However, their semantics generally are so when it comes 
mapping them into BGP-LS.

At this stage, given the advance state of implementations and deployments for 
all these IGP and BGP-LS drafts involved, I don’t think we can undertake such 
“cosmetic” changes.

However, the draft-ietf-idr-bgp-ls-segment-routing-ext-04 is in WGLC and I can 
definitely take your feedback for any updates in the text or clarifications 
necessary in this document. Note that the procedures for the TLVs where 
mappings were non-trivial are described in the Procedures section - 
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-3
 . The TLVs you mention below are very trivial and the mapping from IGPs to 
BGP-LS is straightforward so the authors believe the explanation in Section 2 
where each TLV field is described is sufficient.

In the end, I am not sure if any of this helps/addresses implementation defects 
(where the reserved field itself was skipped from the BGP-LS TLV) that you have 
identified in your deployment on the producer side.

Thanks,
Ketan

From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: 08 April 2018 07:02
To: Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: 'Jeffrey Haas' <jh...@pfrc.org>; lsr@ietf.org; i...@ietf.org
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi, Ketan:

I think there is another reason that causes this semantic error-that is 
there is many similarities for the definition of “Adj-SID Sub-TLV” for ISIS and 
OSPFv3 in the following draft:
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-11#section-6.1
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-15#section-2.2.1

but there is no any description in the relevant paragraph to  distinguish them 
in BGP-LS document.
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-2.2.1


Ketan explained that “ISIS uses 1 byte for type/length and has LSP space 
constraints which you would notice in  the protocol encodings. OSPF doesn’t 
have the same challenge and you would notice how its TLVs tend to be aligned. 
BGP-LS is somewhat similar to OSPF from these size constraints perspective.” 
But when I compared another TLV definition “SRMS Preference TLV” in randomly, I 
found the definition in BGP-LS is different from that both in ISIS and 
OSPFv3.(include the “length” field and “reserved” field) I don’t know there are 
how many inconsistence among them and think this will induce other 
inconsistencies when the vendor implements the BGP-LS protocol.



Can we align these definitions as consistence as possible among them? Or add 
clear distinguish statements for the different IGP protocol?

The consumer can add some detections for such kind semantic errors but the 
better is not to produce them.



Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
发件人: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
发送时间: 2018年4月4日 15:54
收件人: Aijun Wang
抄送: Jeffrey Haas; lsr@ietf.org<mailto:lsr@ietf.org>; 
i...@ietf.org<mailto:i...@ietf.org>
主题: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

< including IDR WG where BGP-LS work is being done >

Hi Aijun,

As discussed offline, this is a bug in this particular implementation where it 
is not following the spec properly.

This goes back to the discussion in the IDR WG about the semantic and syntactic 
validation for BGP-LS messages which Jeff had brought up. In this case, my 
understanding was that there was a semantic error in this TLV encoding? The 
consumer (application/BGP speaker) in this case should detect and ignore this 
update – which is what was being done as well in this case?

Thanks,
Ketan

From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: 04 April 2018 07:50
To: 'stefano previdi' <stef...@previdi.net<mailto:stef...@previdi.net>>; Peter 
Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Ketan Talaulikar (ketant) 
<ket...@cisco.com<mailto:ket...@cisco.com>>; Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing


Hi, All:



We have found some inconsistencies for the implementation of BGP-LS protocol 
regarding this “Adj-SID SubTLV ”, please see the following screenshot.

I think we should do some wo

Re: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

[Ketan Talaulikar (ketant)]

Hi Chris,

I had shared some comments and requests for clarifications on the OSPF MSD 
draft. Some of them are also applicable to the ISIS version. Please find the 
same attached.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 23 April 2018 19:33
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

Hi Folks,

We are starting a new 2 week WG last call on

  https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/

as there have (*) been some changes to the document since our last WG last call 
last year. Here's the diff.

https://www.ietf.org/rfcdiff?url1=draft-ietf-isis-segment-routing-extensions-12=draft-ietf-isis-segment-routing-extensions-16

Will end Monday May 7th.

Thanks,
Chris.

(*) contrary to what you may have heard from folks at the mic in London. :)

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--- Begin Message ---
Hi Acee,



I have reviewed this draft for OSPF but in the same context also gone over its 
corresponding ISIS draft 
(https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ ) and 
some of the comments apply to both since they are mostly identical in content.



I need to ask the question if it makes sense to merge these drafts into a 
single one to save everyone cycles and ensure consistency in the spirit of LSR J



General Qs:

1) There are some differences between the ISIS and OSPF versions of this 
draft. Could I request the authors to please cross-check and fix? The ISIS 
draft does not have some of the issues mentioned below.

2) Do these TLVs apply only when the router is enabled for Segment Routing? 
i.e. they should be originated when SR is enabled on the router and the 
receiver should not expect them when SR is disabled? Or do we foresee MSD to be 
more generic. This aspect needs to be clarified.

3) The allowable values are specified as 0-254 in OSPF draft while ISIS one 
allows 255 as well. The IANA section though says that 255 is reserved.

4) The draft using “sub-type” in some places and “type” in some places. 
This is confusing. The ISIS draft uses “type” everywhere which seems better.

5) Several comments below about the section where OSPF TLVs are defined and 
I would suggest to use similar text as in the ISIS draft.

6) I think it is better that the draft mandates that the  MSD sub-types 
SHOULD be encoded in ascending order? This makes it easier for the 
receiver/consumer to detect absence or removal of a specific sub-type from 
signalling.

7) Reference to RFC4970 should be replaced with RFC7770

8) Both the ISIS and OSPF drafts are asking IANA for creation of MSD type 
registry. Should the creation not be done by only one of them and the other 
points to it?





Sec 1



can be imposed at each node/link on a given SR path

It laso also defines
   the Base MPLS Imposition MSD type.


Sec 1.1.1



   BMI: Base MPLS Imposition is the number of MPLS labels that can be
   imposed inclusive of any all service/transport/special labels



Sec 3



Node MSD is the minimum MSD supported by all the links of the node.

Sub-Type 1 (IANA Section), MSD and the Value field contains maximum
   MSD of the router originating the RI LSA.




Some Qs on Sec 3:

1) In my understanding, the Node MSD is the minimum value of all the Link 
MSDs for the links on that node that are enabled in that specific IGP instance. 
There may be another IGP instance configured on the same node with a different 
set of links and for that instance, the Node MSD may be higher. The same goes 
for links that are not configured/enabled under the specific IGP instance. The 
draft needs to clarify this aspect.

2) The draft needs to specify how many instances of this TLV are allowed in 
the RI LSA and when there are multiple instances in the same or multiple RI LSA 
fragments, then how should the receiver handle or interpret them? E.g. uses the 
minimum of the signalled Node MSD values or uses the first instance of the TLV 
in the lowest fragment, etc. Also, we don’t want multiple instances of the MSD 
TLV to be encoded for different types – all of them must be in a single 
instance of the MSD TLV.



Sec 4



   For OSPFv3, the Link level MSD value is advertised as an optional
   Sub-TLV of the Router-Link E-Router-LSA TLV as defined in
   
[I-D.ietf-ospf-ospfv3-lsa-extend],
 and has value of TBD3.



   Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
   of the link router originating the corresponding LSA as specified for
   OSPFv2 and OSPFv3.



Some Qs on Sec 4:

1) The draft needs to specify how many instances of this TLV are allowed in 
the Extended Link 

Re: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

[Ketan Talaulikar (ketant)]

Please ignore my email below, it is not applicable to the ISIS SR draft in 
subject.

I support draft-ietf-isis-segment-routing-extensions progressing further.

Thanks,
Ketan

-Original Message-
From: Ketan Talaulikar (ketant) 
Sent: 24 April 2018 08:04
To: 'Christian Hopps' <cho...@chopps.org>; lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: RE: [Lsr] WG Last Call for 
draft-ietf-isis-segment-routing-extensions-16

Hi Chris,

I had shared some comments and requests for clarifications on the OSPF MSD 
draft. Some of them are also applicable to the ISIS version. Please find the 
same attached.

Thanks,
Ketan

-Original Message-
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps
Sent: 23 April 2018 19:33
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

Hi Folks,

We are starting a new 2 week WG last call on

  https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/

as there have (*) been some changes to the document since our last WG last call 
last year. Here's the diff.

https://www.ietf.org/rfcdiff?url1=draft-ietf-isis-segment-routing-extensions-12=draft-ietf-isis-segment-routing-extensions-16

Will end Monday May 7th.

Thanks,
Chris.

(*) contrary to what you may have heard from folks at the mic in London. :)

___
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] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

[Ketan Talaulikar (ketant)]

Hi Aijun,

Can you clarify what you mean by "inconsistencies"?

Also, you are referring the old version of OSPFv3 SR draft before it was 
aligned with the OSPFv2 SR draft. Please check 
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-11#section-6.1

OSPF and ISIS are different protocols and there are some differences between 
them. I would not call them inconsistencies. BGP-LS spec refers to the 
individual IGP drafts for interpretation of flags. So please specifically point 
out what inconsistency you are referring to.

Thanks,
Ketan

From: Lsr  On Behalf Of Aijun Wang
Sent: 02 April 2018 14:23
To: lsr@ietf.org
Subject: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing

Hi, All:

We found there were some inconsistences for the definition of "Adjacency 
Segment Identifier" between OSPF and ISIS extension for segment routing, please 
see the link below for comparison.
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-15#section-2.2.1
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-10#section-7.1

Here we want to know is there any reason for this inconsistence? We think this 
inconsistence can easily cause error for BGP-LS implementation for segment 
routing extension, as that defined in 
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#section-2.2.1,
 which is similar with ISIS extension for SR, but different from OSPF extension 
for SR.

Do we need to make them consistent? It seems change the definition in OSPF 
extension may be less influence for the existing related drafts.

Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China..

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

Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

[Ketan Talaulikar (ketant)]

< including IDR WG where BGP-LS work is being done >

Hi Aijun,

As discussed offline, this is a bug in this particular implementation where it 
is not following the spec properly.

This goes back to the discussion in the IDR WG about the semantic and syntactic 
validation for BGP-LS messages which Jeff had brought up. In this case, my 
understanding was that there was a semantic error in this TLV encoding? The 
consumer (application/BGP speaker) in this case should detect and ignore this 
update – which is what was being done as well in this case?

Thanks,
Ketan

From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: 04 April 2018 07:50
To: 'stefano previdi' <stef...@previdi.net>; Peter Psenak (ppsenak) 
<ppse...@cisco.com>
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem 
(acee) <a...@cisco.com>
Subject: 答复: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing


Hi, All:



We have found some inconsistencies for the implementation of BGP-LS protocol 
regarding this “Adj-SID SubTLV ”, please see the following screenshot.

I think we should do some works for the related drafts to clarify this 
ambiguous/easy to be ignored definition.



[cid:image001.png@01D3CC17.DE8CCD40]



Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.



-邮件原件-
发件人: stefano previdi [mailto:stef...@previdi.net]
发送时间: 2018年4月3日 15:39
收件人: Peter Psenak
抄送: lsr@ietf.org<mailto:lsr@ietf.org>; Ketan Talaulikar (ketant); Acee Lindem 
(acee); Aijun Wang
主题: Re: [Lsr] Inconsistence regarding the definition of "Adj-SID Sub-TLV" 
between OSPF and ISIS extension for Segment Routing



me too.



If we want to align the encoding, we should probably better align the protocol 
name directly...



s.





> On Apr 3, 2018, at 9:34 AM, Peter Psenak 
> <ppse...@cisco.com<mailto:ppse...@cisco.com>> wrote:

>

> On 02/04/18 14:19 , Acee Lindem (acee) wrote:

>> Speaking as WG member:

>>

>> I couldn’t agree more with Ketan. No changes are required to these

>> documents.

>

> as a coauthor of the OSPF/OSPFv3 SR drafts, I fully agree.

>

> thanks,

> Peter

>

>>

>> Thanks,

>>

>> Acee

>>

>> *From: *Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of 
>> "Ketan Talaulikar

>> (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>

>> *Date: *Monday, April 2, 2018 at 7:36 AM

>> *To: *Aijun Wang 
>> <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>

>> *Cc: *"lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>

>> *Subject: *Re: [Lsr] Inconsistence regarding the definition of

>> "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

>>

>> Hi Aijun,

>>

>> I understand what you are referring to now, but these are not

>> inconsistencies. ISIS, OSPF and BGP-LS are 3 different protocols.

>> Their encodings may not all be the same. ISIS uses 1 byte for

>> type/length and has LSP space constraints which you would notice in

>> the protocol encodings. OSPF doesn’t have the same challenge and you

>> would notice how its TLVs tend to be aligned. BGP-LS is somewhat

>> similar to OSPF from these size constraints perspective.

>>

>> I do not see the implementation challenges in encoding from the two

>> IGPs into BGP-LS. It does not make sense to change any of the

>> protocol encodings that you ask for currently since implementations

>> have been shipping with them for many years.

>>

>> IMHO it is not necessary to put such constraints for what you call

>> “consistency” on these 3 protocol encodings in the future. However,

>> we do try to be consistent in semantics as much as possible.

>>

>> Thanks,

>>

>> Ketan

>>

>> *From:*Aijun Wang 
>> <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>

>> *Sent:* 02 April 2018 16:52

>> *To:* Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>

>> *Cc:* lsr@ietf.org<mailto:lsr@ietf.org>

>> *Subject:* Re: [Lsr] Inconsistence regarding the definition of

>> "Adj-SID Sub-TLV" between OSPF and ISIS extension for Segment Routing

>>

>> Hi, Ketan:

>>

>> There is one two-bytes “Reserved” field in “Adjacency Segment

>> Identifier” TLV for OSPF extension, but this field doesn’t exist in

>> the corresponding TLV for ISIS extension. Every other fields are same.

>>

>>

Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

[Ketan Talaulikar (ketant)]

Hello All,

I support this simple but important extension.

A couple of minor comments on the draft:


1) Sec 3 says


   A node that implements X-AF routing SHOULD advertise, in the

   corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6

   addresses local to the router that can be used by Constrained SPF

   (CSPF) to calculate MPLS TE LSPs.  In general, OSPF SHOULD advertise

   the IP address listed in the Router Address TLV 
[RFC3630] 
[RFC5329]

   of the X-AF instance maintaining the MPLS TE database, plus any

   additional local addresses advertised by the X-AF OSPF instance in

   its Node Local Address sub-TLVs.  An implementation MAY advertise

   other local X-AF addresses.

Generally speaking, should the IP address (TE router ID in common terms) which 
is candidate for inclusion in the Router Address TLV not be a MUST candidate 
for X-AF advertisement?

I also have a question about the first statement with the SHOULD in it. 
Consider we are using the TE topology from OSPFv2 to compute a tunnel for use 
with OSPFv3. Any IPv6 addresses associated with the OSPFv3 instance on a router 
would be advertised as a Node attribute and would not help identify a specific 
link. So practically, if any IPv6 addresses (if at all) were to be used for 
CSPF then it would just identify the node – in this case, isn’t advertising the 
IPv6 address (TE router ID used in Router Address TLV) sufficient?

For practical deployment, it think it would help if this was clarified that we 
really need only the TE Router ID Address to go X-AF in most/general cases and 
not the others?


2) Isn’t the mapping algorithm in Sec 3 actually going to be used for IGP 
short-cut use-case with its reference to the IGP cost of the tunnel? If so, 
would a reference to rfc3906 be helpful in this document.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 23 October 2018 03:55
To: lsr@ietf.org
Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering 
Tunnels - draft-ietf-ospf-xaf-te-04.txt

This begins an LSR WG last call for the subject draft. Please send your 
comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its 
only an 8 page document, I added an extra week due to the IETF. Please let me 
know if anyone needs any more time.

https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/

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

Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

[Ketan Talaulikar (ketant)]

Agree with Anton on the use of Node IPvX Local Address sub-TLVs as it provides 
the flexibility to advertise more/other addresses. If we were to use IPvX 
Router Address TLVs then we could only do one per node.

My comment was that in most cases, advertising just that one IPvX address 
(generally equivalent to what would have been put in IPvX Router Address TLV) 
is sufficient and that this it should be a MUST (instead of SHOULD). Other 
addresses may be optional as indicated in the draft.

Thanks,
Ketan

-Original Message-
From: Anton Smirnov (asmirnov) 
Sent: 27 October 2018 07:04
To: Alexander Okonnikov 
Cc: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering 
Tunnels - draft-ietf-ospf-xaf-te-04.txt

Hi Alexander,

 > I tend to agree with Ketan, but with slightly different proposal. Would  > 
 > not it be simpler to advertise IPv6 Router Address TLV (TLV type 3) by  > 
 > OSPFv2 Opaque LSA (in addition to advertising of Router Address TLV) and  > 
 > to advertise Router Address TLV (TLV type 1) by OSPFv3 Intra-Area-TE-LSA  > 
 > (in addition to advertising IPv6 Router Address TLV)? In this case we  > can 
 > identify the same router represented by OSPFv2 and OSPFv3 and don't  > need 
 > the extension provided by the draft.

What you are suggesting is essentially the same sort of information 
propagated in different TE TLV. So basically except for TLV type rest of of 
procedures won't change.
When writing the first revision of the draft we did consider doing what you 
are proposing but finally Node IPvX Local Address sub-TLV looked like a better 
match to what we intend to advertise.
Per RFC 5786 Node IPvX Local Address sub-TLV is used to advertise 
additional addresses local to the router. And that is exactly what we use it 
for, to advertise additional router's addresses.

As for the other Ketan's comment - as I already wrote, we will try to 
address it in the next document revision.

---
Anton


On 10/25/18 23:19, Alexander Okonnikov wrote:
> Hi Anton,
> 
> I tend to agree with Ketan, but with slightly different proposal. 
> Would not it be simpler to advertise IPv6 Router Address TLV (TLV type 
> 3) by
> OSPFv2 Opaque LSA (in addition to advertising of Router Address TLV) 
> and to advertise Router Address TLV (TLV type 1) by OSPFv3 
> Intra-Area-TE-LSA (in addition to advertising IPv6 Router Address 
> TLV)? In this case we can identify the same router represented by 
> OSPFv2 and OSPFv3 and don't need the extension provided by the draft.
> 
> Regarding calculation of LSPs towards non-TE addresses - head-end uses 
> non-TE address in order to determine TE Router ID of the tail-end 
> (which holds that non-TE address); then head-end uses TE RID in CSPF 
> calculation (though it will, probably, use that non-TE address as a 
> destination in RSVP-TE signaling). Hence, head-end can hold mapping of 
> destination IP of an LSP to corresponding TE RID of tail-end. Then, if 
> the same head-end attempts to calculate LSP using TEDB from OSPFv3 
> (OSPFv2), it will be able to determine whether LSP already have been 
> signaled using OSPFv2 (OSPFv3) TEDB.
> 
> Also, the draft several times says about using TEDB(s) for calculation 
> of LSPs and, on the other hand, for using LSPs for calculation of OSPF 
> routes. Per my understanding these are two different independent tasks 
> - calculation of LSPs and their usage. The second task is what defined 
> by RFC 3906, and you want to extend it such that SPF for one AF can 
> utilise LSPs as shortcuts, created for other AF. My understanding that 
> these two tasks need to be discussed separately. It could be two 
> different documents, or two different sections of the same one.
> 
> Thank you.
> 
>> 25 окт. 2018 г., в 19:57, Anton Smirnov > <mailto:asmir...@cisco.com>> написал(а):
>>
>>    Hi Ketan,
>>
>> 1. I am not sure I understood the question. Your example says "using 
>> the TE topology from OSPFv2 to compute a tunnel". In that case TE 
>> router ID is an IPv4 address. So no, advertising IPv6 address won't 
>> help to identify the tunnel.
>>
>> 2. my opinion (not discussed with other authors): RFC 3906 is 
>> Informational RFC, so it is not mandatory for implementation to 
>> follow. I think we can insert mention to that RFC somewhere in the 
>> Introduction but wording should be sufficiently weak (like "one 
>> possible example of route computation algorithm...").
>>
>> ---
>> Anton
>>
>> On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote:
>>>
>>> Hello All,
>>>
>>> I support this simple but important extension.
>>&

Re: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering Tunnels" - draft-ietf-ospf-xaf-te-05

[Ketan Talaulikar (ketant)]

Hi All,

The updates to the version 05 of the draft largely address my comments.

Please check inline below for some further comments.


From: Alexander Okonnikov 
Sent: 08 February 2019 15:56
To: Acee Lindem (acee) 
Cc: lsr@ietf.org; draft-ietf-ospf-xaf...@ietf.org; Gunter Van de Velde 
; Ketan Talaulikar (ketant) 
Subject: Re: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering 
Tunnels" - draft-ietf-ospf-xaf-te-05

Hi Acee,

For me current version doesn't change the solution. My comments are follow:

1.  Introduction

"TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been described to 
support intra-area TE in IPv4 and IPv6 networks, respectively.  In both cases, 
the TE database provides a tight coupling between the routed protocol and 
advertised TE signaling information.  In other words, any use of the TE link 
state database is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 
[RFC5340]."

What is meant for "routed protocol"?
[KT] I believe this should be “routing protocol”?
Is it passenger protocol of RSVP-TE LSPs, protocol used as a transport for RSVP 
signaling, protocol for which OSPFv2/OSPFv3 calculate routes?  What does mean 
"TEDB is limited to IPv4/IPv6"? Is it limited to choose IPv4/IPv6 as a 
transport for RSVP-TE LSP signaling?

"For example, an LSP created based on MPLS TE information propagated by an 
OSPFv2 instance can be used to transport both IPv4 and IPv6 traffic, as opposed 
to using both OSPFv2 and OSPFv3 to provision a separate LSP for each address 
family."

An LSP created based on TEDB from OSPFv2 can be used to transport IPv4 and IPv6 
without extensions, proposed in the draft. We are not obligated to signal 
RSVP-TE LSPs from OSPFv2 TEDB for IPv4 traffic and other RSVP-TE LSPs from 
OSPFv3 TEDB for IPv6 traffic. RSVP-TE LSPs signaled based on TEDB from either - 
OSPFv2 or OSPFv3 - can be used for transport either - IPv4 or IPv6 - traffic. 
I.e. payload of RSVP-TE LSP and transport protocol for its signaling are not 
obligated to be the same. I guess that authors meant that an LSP, based on MPLS 
TE from OSPFv2, can be used for calculation of shortcuts by OSPFv2, and not by 
OSPFv3.
[KT] Yes. I believe the authors are referring to limitations in use of IGP 
shortcuts across AFs.

Authors provide description of possible solution with common Router ID. I 
propose similar solution with advertising both Router IDs (OSPFv2 and OSPFv3) 
in both instances (OSPFv2 and OSPFv3). Latter overcomes issues with correctness 
of configuration and out of sync. Also, I don't understand how can possible 
solution with common Router ID have problem with different placement of ABRs in 
OSPFv2 and OSPFv3. We are talking about intra-area LSPs, hence tail-end router 
should be within area in both instances.
[KT] Using common Router IDs and advertising across each AFs is an option, but 
personally, I find the use of Node Attribute TLV provides better flexibility.

Thanks,
Ketan


3.  Operation

"A node that implements X-AF routing SHOULD advertise, in the corresponding 
Node Local Address sub-TLV, all X-AF IPv4 and IPv6 addresses local to the 
router that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs."

From section 1 we assume that X-AF is used for calculation of shortcuts. Why 
does the draft say here about calculation of TE LSPs by CSPF?

"If the Node Attribute TLV carries both the Node IPv4 Local Address sub-TLV and 
the Node IPv6 Local Address sub-TLV, then the X-AF component MUST be considered 
for the consolidated calculation of MPLS TE LSPs."

The same.


Thanks.



31 янв. 2019 г., в 2:03, Acee Lindem (acee) 
mailto:a...@cisco.com>> написал(а):

Hi Gunter, Alex, Ketan,
I hoping everyone who commenting on the previous version is happy with the 
version. I’m extending the WG last call another week to see if we have any 
objections to this version.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem mailto:a...@cisco.com>>
Date: Monday, January 7, 2019 at 11:47 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "draft-ietf-ospf-xaf...@ietf.org<mailto:draft-ietf-ospf-xaf...@ietf.org>" 
mailto:draft-ietf-ospf-xaf...@ietf.org>>
Subject: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering 
Tunnels" - draft-ietf-ospf-xaf-te-05

This begins an LSR WG last call for the subject draft. Please send your
comments to this list prior to 12:00 AM GMT, January 22nd, 2019.

Note that the second IPR poll was completed in December.

Thanks,
Acee

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

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Ketan Talaulikar (ketant)]

I support the adoption of this draft by the WG.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 11 February 2019 16:15
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.


Hi Folks,

We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.

The aim of this document is to describe the problem space and standardize a way 
to signal dynamic flooding information. It does not standardize any specific 
algorithm for flooding topology creation.

Authors please respond indicating if you are aware of any IPR related to this 
work.

We also have another draft (draft-cc-lsr-flooding-reduction-01) that started as 
a distributed flooding topology algorithm and morphed into that plus competing 
ideas on signaling of flooding topology information. The intent after adoption 
of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG can discuss adding 
any signaling ideas from this work to the adopted signaling draft (with proper 
attribution given as appropriate), and two, for the authors of 
draft-cc-lsr-flooding-reduction-01 to publish a new document without the 
signaling portion and instead focus on their flooding topology algorithm. This 
new focused document can be considered in parallel along with the other 
algorithm work that has been proposed.

Flooding topology creation is seen as a hard problem for which we don't expect 
a one-size-fits-all solution. Taking the steps outlined above will help us move 
forward on the solutions.

Thanks,
Chris & Acee.
LSR WG Chairs.

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

Re: [Lsr] draft-ketant-idr-bgp-ls-bgp-only-fabric

[Ketan Talaulikar (ketant)]

Hi Robert,

Please check inline below.

From: Robert Raszuk 
Sent: 10 March 2019 21:40
To: Ketan Talaulikar (ketant) 
Cc: idr@ietf. org ; lsr@ietf.org
Subject: draft-ketant-idr-bgp-ls-bgp-only-fabric

Hi Ketan,

I have read your proposal of defining topology flooding in BGP with interest.

It seems like a pretty brilliant twist to take pieces defined in other 
documents with their original intention for sending IGP information (LSDB or 
TED) over BGP extension and now use all of those without IGP at all :).
[KT] RFC7752 did always have “direct” and “static” protocols – so it was not 
just IGPs. We extended to include BGP protocol for describing Peering topology 
for the EPE use-case with draft-ietf-idr-bgpls-segment-routing-epe

But I have just one question here perhaps to the WG or ADs.

Almost all normative references used in this draft clearly state that they were 
defined for carrying information present in ISIS & OSPF protocols as rather a 
courtesy of transporting them over TCP with BGP envelope between network and 
controller.

Can we now just "reuse" verbatim all of those defined codepoints as well as 
redefine use of BGP-LS SAFI as a new link state p2p network topology transport 
just like that ?
[KT] The BGP-LS SAFI is still used to report link-state information. This draft 
describes how it can be done even when no IGP is running and we are instead 
running BGP protocol (in RFC7938 hop-by-hop routing design). Each router here 
is setting up a BGP-LS session with a controller or a centralized BGP speaker 
to report the router’s own node properties, links, prefixes, etc. The objective 
is build a link-state topology at the controller for specific use-cases like 
topology discovering and TE with SR as described in Sec 6 of the draft.

At min I would like to see some analysis included in this draft of running 
native link state protocol possibly with dynamic flooding optimization vs 
running BGP as the only routing protocol with using BGP as topology discovery 
transport before we proceed further on this document.
[KT] I am not sure I see the contrast here. Personally, I support the dynamic 
flooding optimization work in LSR. There are already DC networks deployed with 
RFC7938 design. All this draft is introducing is topology discovery and other 
use-cases in the latter.

Thanks,
Ketan

Kind regards,
Robert.

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

[Lsr] FW: New Version Notification for draft-ketant-lsr-ospf-bfd-strict-mode-00.txt

[Ketan Talaulikar (ketant)]

Hello All,

We've posted a draft for BFD operations for OSPF. Would appreciate review and 
feedback from the LSR and BFD WGs.

rfc6213 addresses similar problem for IS-IS.

Thanks,
Ketan

-Original Message-
From: internet-dra...@ietf.org  
Sent: 05 March 2019 00:00
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 

Subject: New Version Notification for 
draft-ketant-lsr-ospf-bfd-strict-mode-00.txt


A new version of I-D, draft-ketant-lsr-ospf-bfd-strict-mode-00.txt
has been successfully submitted by Ketan Talaulikar and posted to the IETF 
repository.

Name:   draft-ketant-lsr-ospf-bfd-strict-mode
Revision:   00
Title:  OSPF BFD Strict-Mode
Document date:  2019-03-04
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-ketant-lsr-ospf-bfd-strict-mode-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/
Htmlized:   
https://tools.ietf.org/html/draft-ketant-lsr-ospf-bfd-strict-mode-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode


Abstract:
   This document specifies the extensions to OSPF that enables a router
   and its neighbor to signal their intention to use Bidirectional
   Forwarding Detection (BFD) for their adjacency using link-local
   advertisement between them.  The signaling of this BFD enablement,
   allows the router to block and not allow the establishment of
   adjacency with its neighbor router until a BFD session is
   successfully established between them.  The document describes this
   "strict-mode" of BFD establishment as a prerequisite to OSPF
   adjacency formation.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Ketan Talaulikar (ketant)]

Hi Acee,

I am not aware of any IPR other than the one disclosed below.

Thanks,
Ketan

From: Aijun Wang 
Sent: 13 February 2019 07:19
To: Acee Lindem (acee) ; 
draft-wang-lsr-ospf-prefix-originator-...@ietf.org
Cc: lsr@ietf.org
Subject: 答复: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Hi, Acee:

Apart from the IPR declared in https://datatracker.ietf.org/ipr/3420/ , I am 
not aware of any other IPR.
Thanks for your efforts.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年2月9日 1:01
收件人: 
draft-wang-lsr-ospf-prefix-originator-...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Authors,

In preparation for a WG adoption call:

Are you aware of any IPR relating to 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-prefix-originator-ext? If 
so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details). If you are listed as a document 
author or contributor please respond to this email regardless of whether or not 
you are aware of any relevant IPR. *The response needs to be sent to the LSR WG 
mailing list.* The document will not advance to the next stage until a response 
has been received from each author and contributor. If you are on the LSR WG 
email list but are not listed as an author or contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] IPR Poll for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (adding contributors)

[Ketan Talaulikar (ketant)]

Hello,

I am not aware of any IPR that applies to this draft.

Thanks,
Ketan

From: Acee Lindem (acee)
Sent: 11 April 2019 03:06
To: draft-ietf-isis-te-...@ietf.org; Ketan Talaulikar (ketant) 
; Acee Lindem (acee) ; Hannes Gredler 

Cc: lsr@ietf.org
Subject: IPR Poll for "IS-IS TE Attributes per application" - 
draft-ietf-isis-te-app-06.txt (adding contributors)

Authors, Contributors,

Are you aware of any IPR that applies to draft-ietf-isis-te-app-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] IPR Poll for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

[Ketan Talaulikar (ketant)]

Hello,

I am not aware of any IPR related to this draft.

Thanks,
Ketan

From: Acee Lindem (acee)
Sent: 11 April 2019 21:40
To: draft-ietf-ospf-te-link-attr-re...@ietf.org
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) ; Hannes Gredler 
; Acee Lindem (acee) 
Subject: IPR Poll for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - 
draft-ietf-ospf-te-link-attr-reuse-07.txt

Authors, Contributors,

Are you aware of any IPR that applies to draft-ietf-ospf-te-link-attr-reuse-07?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] IPR Poll for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Ketan Talaulikar (ketant)]

Hi Acee,

As a contributor, I am not aware of any undisclosed IPR for this draft.

Thanks,
Ketan

From: Acee Lindem (acee)
Sent: 09 May 2019 20:12
To: Stefano Previdi ; Paul Wells (pauwells) 
; daniel.vo...@bell.ca; Ketan Talaulikar (ketant) 
; satoru.matsush...@g.softbank.co.jp; 
bart.peir...@proximus.com; hani.elma...@ericsson.com; 
p...@barefootnetworks.com; msha...@barefootnetworks.com; Robert Hanzl (rhanzl) 

Cc: lsr@ietf.org
Subject: Re: IPR Poll for "IS-IS Extensions to Support Routing over IPv6 
Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

This poll also applies to the ten contributors…

From: Acee Lindem mailto:a...@cisco.com>>
Date: Thursday, May 9, 2019 at 10:23 AM
To: 
"draft-bashandy-isis-srv6-extensi...@ietf.org<mailto:draft-bashandy-isis-srv6-extensi...@ietf.org>"
 
mailto:draft-bashandy-isis-srv6-extensi...@ietf.org>>
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: IPR Poll for "IS-IS Extensions to Support Routing over IPv6 Dataplane" 
- draft-bashandy-isis-srv6-extensions-05.txt

Authors,

Are you aware of any IPR that applies to
draft-bashandy-isis-srv6-extensions-05.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Ketan Talaulikar (ketant)]

Support the adoption of this draft.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 09 May 2019 19:20
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support 
Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

We been holding off WG adoption until the base SRv6 draft was adopted in 
SPRING. Now that 
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ 
has been adopted, we are starting a two week LSR WG adoption poll for the 
subject draft. Please register your support or objection prior to 12:00 AM UTC, 
on May 25th, 2019.

For your convenience, here is a URL for the draft:

https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/

Thanks,
Acee

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

Re: [Lsr] Adjacency SID and Passive Interface

[Ketan Talaulikar (ketant)]

+1

Hi Oliver,

Technically Adj-SID refers to an IGP adjacency between two nodes as per RFC8402 
semantics. I don't think a passive (stub) link falls under that category. It 
would be better to define a passive link separately (somewhat on lines of what 
was done for inter-AS TE) so that it does not get mixed up with the classical 
IGP links. I would think a new draft would be apt for such an extension.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 10 May 2019 17:39
To: Christian Franke ; olivier.dug...@orange.com; 
SPRING ; LSR 
Subject: Re: [Lsr] Adjacency SID and Passive Interface

Hi Chris, Olivier, 

On 5/10/19, 4:41 AM, "Lsr on behalf of Christian Franke"  wrote:

On 5/10/19 9:58 AM, olivier.dug...@orange.com wrote:
> In the current state of Segment Routing drafts, do you think it is 
possible to advertise
> Adjacency SID on such passive or inter-domain interfaces or do we need to 
specify this behaviour
> in a new draft ?
> 
> For me I don't see anything in the drafts that prohibits this kind of 
advertisement, but perhaps I'm wrong.

My understanding is that the SID is specific to an adjacency and
advertised in IS-IS in either TLV 22, 222, 23, 223.

As adjacencies will not be formed on a passive interface, an adjacency
SID should not be advertised for the passive interface.

I agree with Chris. We shouldn't reuse the existing Adj-SID when there will 
never be an adjacency and the current semantics require this. If we need 
advertisement of SIDs for passive interfaces, it would definitely be a new 
draft that clearly articulates the use case and designates a new type of SID 
that has different semantics. Also note that while passive interfaces are very 
useful in order to include a stub network in the topologies, they are not part 
of the OSPF specifications. I haven't done an exhaustive search on IS-IS. 

Thanks,
Acee


I might also be wrong here, though.

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

[Lsr] Update for draft-ketant-lsr-ospf-bfd-strict-mode-02.txt

[Ketan Talaulikar (ketant)]

Hello All,

We've posted an update for the OSPF Strict Mode for BFD operations that 
incorporates feedback and inputs received from WG members.

Mainly :
1) Strict Mode working for OSPFv3 IPv4 AF instances
2) Clarifications on interactions with GR operations

We would welcome further review/comments/feedback/contributions from the WG.

Thanks,
Ketan & Peter


-Original Message-
From: internet-dra...@ietf.org  
Sent: 08 July 2019 17:36
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 

Subject: New Version Notification for 
draft-ketant-lsr-ospf-bfd-strict-mode-02.txt


A new version of I-D, draft-ketant-lsr-ospf-bfd-strict-mode-02.txt
has been successfully submitted by Ketan Talaulikar and posted to the IETF 
repository.

Name:   draft-ketant-lsr-ospf-bfd-strict-mode
Revision:   02
Title:  OSPF Strict-Mode for BFD
Document date:  2019-07-08
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-ketant-lsr-ospf-bfd-strict-mode-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/
Htmlized:   
https://tools.ietf.org/html/draft-ketant-lsr-ospf-bfd-strict-mode-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ketant-lsr-ospf-bfd-strict-mode-02

Abstract:
   This document specifies the extensions to OSPF that enables a router
   and its neighbor to signal their intention to use Bidirectional
   Forwarding Detection (BFD) for their adjacency using link-local
   advertisement between them.  The signaling of this BFD enablement,
   allows the router to block and not allow the establishment of
   adjacency with its neighbor router until a BFD session is
   successfully established between them.  The document describes this
   OSPF "strict-mode" of BFD establishment as a prerequisite to
   adjacency formation.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Ketan Talaulikar (ketant)]

Hi Sue,

No other question.

Thanks,
Ketan

From: Susan Hares 
Sent: 26 July 2019 15:19
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: i...@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org
Subject: RE: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

Ketan

Yep.  That's the mechanism.  Was there another question?

Sue


Sent via the Samsung Galaxy S7 edge, an AT 4G LTE smartphone

 Original message 
From: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.com>>
Date: 7/26/19 11:54 AM (GMT-05:00)
To: Susan Hares mailto:sha...@ndzh.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, lsr@ietf.org<mailto:lsr@ietf.org>
Cc: i...@ietf.org<mailto:i...@ietf.org>, 
draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org<mailto:draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org>
Subject: RE: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

Hi Sue,

In this specific case, I would like to point that we would be marking an IDR WG 
document 
(https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/) 
as being “replaced” by the 2 LSR documents below.

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

Thanks,
Ketan

From: Susan Hares mailto:sha...@ndzh.com>>
Sent: 25 July 2019 22:58
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Acee 
Lindem (acee) mailto:a...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org<mailto:draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org>
Subject: RE: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

Ketan and Acee:

The IDR co-chairs (John and I) wish to reduce the number of trivial drafts for 
BGP-LS allocations that could be done with 1 sentence.   We discussed with the 
LSR chairs (Acee and Chris) that it would be reasonable for LSR to do what 
Ketan has requested.

We suggest that the WG LC is sent to IDR and LSR in case someone wants to 
discuss a concern.   The LSR chairs are capable and smart.   Acee and Chris can 
help shepherd these LSR drafts with BGP TLV language.

Sue

PS – has anyone heard if Chris Hopps is a father yet?


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 25, 2019 6:43 PM
To: Acee Lindem (acee); lsr@ietf.org<mailto:lsr@ietf.org>
Cc: i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org<mailto:draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org>
Subject: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

Hi Acee/All,

During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
aspects of the following two IGP drafts in those drafts instead of requiring a 
separate document:

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

Originally, these IGP drafts introduced a new node capability that required a 
new BGP-LS TLV and this was captured in the IDR WG document 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

However after the discussion in the LSR WG over the last few months, the 
approach has changed such that the IGP signalling is being done by introduction 
of new flags and MSD-type. This makes the corresponding BGP-LS updates quite 
trivial and as discussed in the LSR WG, I would recommend to add some text 
(proposed below) to the two IGP documents.

OSPF:

The OSPF extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for OSPF by this document is advertised using 
the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].

ISIS:

The IS-IS extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV where 
the ELC Flag is introduced in this document is advertised using the Prefix 
Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for IS-IS by this document is advertised 
using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].



I am copying the IDR WG and authors of the BGP-LS ERLD draft

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This 
“BFD hold up” behaviour that you desire is best handled by BFD since I would 
expect that similar behaviour would be desired across routing protocols (OSPF, 
ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this 
BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should 
however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr  On Behalf Of Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' ; i...@ietf.org
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG 
process.  Can this small change be made after adoption or should it be made 
before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120 
PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: i...@ietf.org
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make 
this draft more operationally useful.

We have encountered several traffic blackhole problems in our production 
network without this feature. As such, we have deployed BGP with strict BFD 
mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
break in the middle issues, the traditional knobs like interface 
hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like 
to request that an option be added in "Section 4 Operation:" to delay BGP from 
coming up until BFD is proven stable continuously for a period of time (i.e. 
BFD hold up feature).

This is a feature that we are currently using in the proprietary vendor 
deployment. In our case, since we have multiple redundant paths, we have some 
links where we delay BGP from coming up until BFD has been stable continuously 
for 60 seconds.

Thanks
Albert Fu
Bloomberg

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

[Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Ketan Talaulikar (ketant)]

Hi Acee/All,

During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
aspects of the following two IGP drafts in those drafts instead of requiring a 
separate document:

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

Originally, these IGP drafts introduced a new node capability that required a 
new BGP-LS TLV and this was captured in the IDR WG document 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

However after the discussion in the LSR WG over the last few months, the 
approach has changed such that the IGP signalling is being done by introduction 
of new flags and MSD-type. This makes the corresponding BGP-LS updates quite 
trivial and as discussed in the LSR WG, I would recommend to add some text 
(proposed below) to the two IGP documents.

OSPF:

The OSPF extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for OSPF by this document is advertised using 
the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].

ISIS:

The IS-IS extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV where 
the ELC Flag is introduced in this document is advertised using the Prefix 
Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for IS-IS by this document is advertised 
using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].



I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for their 
inputs/feedback.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 25 July 2019 16:28
To: lsr@ietf.org
Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes

I think we had some very good discussions in our sessions this week. I’ve 
uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
Yingzhen Qu for taking them.

https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00

Thanks,
Acee

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

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Ketan Talaulikar (ketant)]

Hi Sue,

In this specific case, I would like to point that we would be marking an IDR WG 
document 
(https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/) 
as being “replaced” by the 2 LSR documents below.

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

Thanks,
Ketan

From: Susan Hares 
Sent: 25 July 2019 22:58
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: i...@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org
Subject: RE: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

Ketan and Acee:

The IDR co-chairs (John and I) wish to reduce the number of trivial drafts for 
BGP-LS allocations that could be done with 1 sentence.   We discussed with the 
LSR chairs (Acee and Chris) that it would be reasonable for LSR to do what 
Ketan has requested.

We suggest that the WG LC is sent to IDR and LSR in case someone wants to 
discuss a concern.   The LSR chairs are capable and smart.   Acee and Chris can 
help shepherd these LSR drafts with BGP TLV language.

Sue

PS – has anyone heard if Chris Hopps is a father yet?


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 25, 2019 6:43 PM
To: Acee Lindem (acee); lsr@ietf.org<mailto:lsr@ietf.org>
Cc: i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org<mailto:draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org>
Subject: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

Hi Acee/All,

During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
aspects of the following two IGP drafts in those drafts instead of requiring a 
separate document:

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

Originally, these IGP drafts introduced a new node capability that required a 
new BGP-LS TLV and this was captured in the IDR WG document 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

However after the discussion in the LSR WG over the last few months, the 
approach has changed such that the IGP signalling is being done by introduction 
of new flags and MSD-type. This makes the corresponding BGP-LS updates quite 
trivial and as discussed in the LSR WG, I would recommend to add some text 
(proposed below) to the two IGP documents.

OSPF:

The OSPF extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for OSPF by this document is advertised using 
the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].

ISIS:

The IS-IS extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV where 
the ELC Flag is introduced in this document is advertised using the Prefix 
Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for IS-IS by this document is advertised 
using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].



I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for their 
inputs/feedback.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: 25 July 2019 16:28
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes

I think we had some very good discussions in our sessions this week. I’ve 
uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
Yingzhen Qu for taking them.

https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00

Thanks,
Acee

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

[Lsr] Update to OSPFv3 SRv6 extensions draft for review/feedback

[Ketan Talaulikar (ketant)]

Hello All,

We've posted an update to the OSPFv3 SRv6 specifications that is now aligned 
with the ISIS SRv6 spec that was adopted by the WG 
(https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/).

We welcome comments and feedback from the WG.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: internet-dra...@ietf.org  
Sent: 08 July 2019 18:12
To: Peter Psenak (ppsenak) ; Zhenbin Li 
; Dean Cheng ; Zhibo Hu 
; Ketan Talaulikar (ketant) 
Subject: New Version Notification for 
draft-li-ospf-ospfv3-srv6-extensions-04.txt


A new version of I-D, draft-li-ospf-ospfv3-srv6-extensions-04.txt
has been successfully submitted by Ketan Talaulikar and posted to the IETF 
repository.

Name:   draft-li-ospf-ospfv3-srv6-extensions
Revision:   04
Title:  OSPFv3 Extensions for SRv6
Document date:  2019-07-08
Group:  Individual Submission
Pages:  21
URL:
https://www.ietf.org/internet-drafts/draft-li-ospf-ospfv3-srv6-extensions-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-ospf-ospfv3-srv6-extensions/
Htmlized:   
https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-ospf-ospfv3-srv6-extensions
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-li-ospf-ospfv3-srv6-extensions-04

Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths by encoding paths as sequences of topological sub-paths, called
   "segments".  Segment routing architecture can be implemented over an
   MPLS data plane as well as an IPv6 data plane.  This draft describes
   the OSPFv3 extensions required to support Segment Routing over an
   IPv6 data plane (SRv6).



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Lsr] "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

[Ketan Talaulikar (ketant)]

Hi Acee,

Thanks for your review and comments. Please check inline below.

From: Acee Lindem (acee) 
Sent: 18 November 2019 06:18
To: draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 
Questions/Comments

Hi Authors,
I know you have asked for adoption and I have some comments on the draft. I 
think these need to be addressed or at least answered prior to any LSR adoption 
call. In my opinion, this document is not ready.


  1.  Why do you define a separate SRv6 Locator LSA to advertise SRv6 
reachability? One of the primary benefits of RFC8362 is to advertise all the 
information associated with a prefix in one LSA. Now you have negated that 
benefit by putting this information in a separate LSA.
[KT] We need to define a new LSA since this is not an extension for the normal 
prefix reachability. For doing FlexAlgo with SRv6, the locators are used for 
reachability computation within the FlexAlgo. If these were advertised as 
normal prefix reachability then routers which are not part of the FlexAlgo or 
even routers not supporting SRv6 would program them. We’ve tried to explain 
this in 
https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5.

Note that in ISIS, the SRv6 Locators are introduced as a new top-level TLV 
along side the Prefix Reachability TLV. So what we propose in OSPFv3 is 
consistent with that model.


  1.  Why do always advertise 128 bit values even when you don’t need it? You 
should only advertise the part of the Locator or SID required dependent on the 
LOC:FUNCTION split (padded to a 4 octet boundary). I would expect the SIDs the 
are Sub-TLVs of the Locator TLV would have that locator in the high-order bit…
[KT] I believe the Locator being a prefix can be advertised only up to the LOC 
part – similar to how it’s done for IS-IS. The SID is being advertised as a 
128-bit value (IPv6 address and not subnet/prefix) and hence we’ve tried to be 
consistent with the same in OSPFv3 as well.


  1.  Similarly, what is the purpose of the SRv6 SID Structure Sub-TLV? 
ietf-spring-srv6-network-programming defines the locator to the first N bits 
and the function to the remaining 128-N bits so I don’t see the need for this 
TLV. At the very least, there should be text defining how it is used.
[KT] This is consistent with 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-3.1

Also, some editorial comments to make the text consistent with other OSPF 
documents.


  1.  There is a mixture of US English and UK English of preferred spellings. 
Please use the US English as the is the style of IETF documents. For example, 
lose the extra “u” in “behavior”.
  2.  OSPF doesn’t define sub-sub-TLVs, sub-sub-sub-TLVs, or any other 
alliterative TLSs.  This is an IS-IS artifact. Any TLV that is not a top-level 
TLV is a Sub-TLV and can be defined at any level of nesting. The GMPLS optical 
encodings in OSPF are very heavily nested.
  3.  Sub-TLV is capitalized, not “sub-TLVs”.
[KT] Mea culpa … we’ll fix all of these in the next update.

Thanks,
Ketan

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

Re: [Lsr] "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

[Ketan Talaulikar (ketant)]

Hi Acee,

Please check inline below.

From: Acee Lindem (acee) 
Sent: 18 November 2019 08:42
To: Ketan Talaulikar (ketant) ; 
draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: Re: "OSPFv3 Extensions for SRv6" - 
draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

Hi Ketan,

From: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.com>>
Date: Monday, November 18, 2019 at 7:24 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"draft-li-ospf-ospfv3-srv6-extensi...@ietf.org<mailto:draft-li-ospf-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-li-ospf-ospfv3-srv6-extensi...@ietf.org>>
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: "OSPFv3 Extensions for SRv6" - 
draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

Hi Acee,

Thanks for your review and comments. Please check inline below.

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: 18 November 2019 06:18
To: 
draft-li-ospf-ospfv3-srv6-extensi...@ietf.org<mailto:draft-li-ospf-ospfv3-srv6-extensi...@ietf.org>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 
Questions/Comments

Hi Authors,
I know you have asked for adoption and I have some comments on the draft. I 
think these need to be addressed or at least answered prior to any LSR adoption 
call. In my opinion, this document is not ready.


1. Why do you define a separate SRv6 Locator LSA to advertise SRv6 
reachability? One of the primary benefits of RFC8362 is to advertise all the 
information associated with a prefix in one LSA. Now you have negated that 
benefit by putting this information in a separate LSA.
[KT] We need to define a new LSA since this is not an extension for the normal 
prefix reachability. For doing FlexAlgo with SRv6, the locators are used for 
reachability computation within the FlexAlgo. If these were advertised as 
normal prefix reachability then routers which are not part of the FlexAlgo or 
even routers not supporting SRv6 would program them. We’ve tried to explain 
this in 
https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5.

Note that in ISIS, the SRv6 Locators are introduced as a new top-level TLV 
along side the Prefix Reachability TLV. So what we propose in OSPFv3 is 
consistent with that model.

Ok – I thought one advantage of SRv6 is that you simply route through routers 
that don’t support SRv6? If you don’t program the locator in these, how does 
this work?
[KT2] This is definitely the advantage and we leverage it for the default SPT. 
For the non-default FlexAlgorithms we want to ensure that only the SRv6 capable 
routers participating in that algo program forwarding entries for it.


2. Why do always advertise 128 bit values even when you don’t need it? You 
should only advertise the part of the Locator or SID required dependent on the 
LOC:FUNCTION split (padded to a 4 octet boundary). I would expect the SIDs the 
are Sub-TLVs of the Locator TLV would have that locator in the high-order bit…
[KT] I believe the Locator being a prefix can be advertised only up to the LOC 
part – similar to how it’s done for IS-IS. The SID is being advertised as a 
128-bit value (IPv6 address and not subnet/prefix) and hence we’ve tried to be 
consistent with the same in OSPFv3 as well.

I guess an advantage of this 128-bit format is that it makes the value easier 
to consume? However, with this full expansion, you also need to check that the 
Locator is consistent with the top-level TLV.
[KT2] Yes, and we have this text in Sec 7 that says so

The
   SRv6 End SID MUST be a subnet of the associated Locator.  SRv6 End
   SIDs which are NOT a subnet of the associated locator MUST be
   ignored.

Thanks,
Ketan

Thanks,
Acee



3. Similarly, what is the purpose of the SRv6 SID Structure Sub-TLV? 
ietf-spring-srv6-network-programming defines the locator to the first N bits 
and the function to the remaining 128-N bits so I don’t see the need for this 
TLV. At the very least, there should be text defining how it is used.
[KT] This is consistent with 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-3.1

Also, some editorial comments to make the text consistent with other OSPF 
documents.


1. There is a mixture of US English and UK English of preferred spellings. 
Please use the US English as the is the style of IETF documents. For example, 
lose the extra “u” in “behavior”.

2. OSPF doesn’t define sub-sub-TLVs, sub-sub-sub-TLVs, or any other 
alliterative TLVs.  This is an IS-IS artifact. Any TLV that is not a top-level 
TLV is a Sub-TLV and can be defined at any level of nesting. The GMPLS optical 
encodings in OSPF are very heavily nested.

3. Sub-TLV is capitalized, not “sub-TLVs”.
[KT] Mea culpa … we’ll fix all of these in the next update.

Thanks,
Ketan

Thank

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

[Ketan Talaulikar (ketant)]

I support this document adoption as a co-author and I am not aware of any IPR 
associated with it.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 13 December 2019 16:58
To: lsr@ietf.org
Cc: Christian Hopps ; 
draft-ketant-lsr-ospf-reverse-met...@ietf.org; lsr-...@ietf.org
Subject: WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

Hi LSR WG and Draft Authors,

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reverse-metric/

Please indicate your support or objection by Dec 27th.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & Acee.

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

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

I support the adoption of the document as a co-author and I am not aware of any 
IPR associated with it.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 13 December 2019 17:25
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; 
draft-ketant-lsr-ospf-bfd-strict-m...@ietf.org
Subject: WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

Hi LSR WG and Draft Authors,

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/

Please indicate your support or objection by Dec 27th.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & Acee.

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

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[Ketan Talaulikar (ketant)]

+1 – I also support the adoption of this document by the WG.

Thanks,
Ketan

From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: 05 December 2019 11:13
To: Acee Lindem (acee) ; lsr@ietf.org
Cc: Christian Hopps 
Subject: Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - 
draft-hopps-lsr-yang-isis-reverse-metric-02

I support adoption of this necessary work.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Monday, November 25, 2019 4:27 AM
To: lsr@ietf.org
Cc: Christian Hopps mailto:cho...@chopps.org>>
Subject: [Lsr] "YANG Module for IS-IS Reverse Metric" - 
draft-hopps-lsr-yang-isis-reverse-metric-02

This begins a two week LSR Working Group adoption call for the subject document.

https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/

Please indicate your support or objection to adoption to the LSR list 
(lsr@ietf.org) prior to 12:00 AM UTC on December 10th, 
2019.

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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

You are right in that there is no assumption that all SRv6 locators in a domain 
are allocated from the same block. Therefore knowing the blocks used in the 
domain is useful.

The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

Thanks,
Ketan

From: Chris Bowers 
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) 
Cc: Ketan Talaulikar (ketant) ; 
lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 
; Bruno Decraene 
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

Based on current documents, allocating all SRv6 locators used in a domain from 
a single block is optional.

However, assuming for the moment that a network operator has chosen to allocate 
all SRv6 locators used in a domain from a single block, so that there is a 
well-defined value of B and N across a domain, what is the use of having a 
router advertise its own understanding of these two values?  And what is a 
receiver supposed to do with this information?

Thanks,
Chris

On Fri, Feb 28, 2020 at 8:23 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) 
[mailto:ket...@cisco.com<mailto:ket...@cisco.com>]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List; 
draft-ietf-spring-srv6-network-programming; Peter Psenak (ppsenak)
Subject: RE: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

[Bruno]
To clarify, my question was not specific to “block” but related to the usage, 
by the receiver, of the following piece of information:

  LB Length: SRv6 SID Locator Block length
  LN Length: SRv6 SID Locator Node length
  Fun. Length: SRv6 SID Function length
  Arg. Length: SRv6 SID Arguments length


So perhaps I don’t get Chris’s point and would wait for him to clarify.
[Bruno] I’ll leave this to Chris.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) 
mailto:40cisco@dmarc.ietf.org>>; Chris 
Bowers mailto:chrisbowers.i...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

Thanks,
Ketan

From: Lsr  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

So perhaps I don’t get Chris’s point and would wait for him to clarify.

Thanks,
Ketan

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM


Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Support. As a contributor, I am not aware of any undisclosed IPR related to 
this draft.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Paul Wells (pauwells)
Sent: 24 January 2020 06:10
To: cho...@chopps.org; lsr@ietf.org
Cc: lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Support. Not aware of any undisclosed IPR.

Paul

On Tue, 2020-01-21 at 19:14 -0500, Christian Hopps wrote:
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com 
Sent: 30 January 2020 08:46
To: Christian Hopps ; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to which the router can apply Penultimate
   Segment Pop (PSP) or Ultimate Segment Pop (USP)


NEW: The Maximum End Pop MSD Type specifies the maximum number of SIDs in

   the SRH for which the router can apply Penultimate

   Segment Pop (PSP) or Ultimate Segment Pop (USP)

2. The abbreviations used in this draft should be listed in a seperated section 
or point out where they are defined.
[KT] We've followed the convention of expanding on first use as also providing 
reference where necessary. Please do let know if we've missed doing so anywhere.

3. Algorithm field is defined for End.x SID to carry the algorithm the end.x 
sid associates. But no algorithm field is defined for End SID in section 7. May 
I know the reason?
[KT] The SRv6 Locator TLV that is the parent of the SRv6 End SID Sub-TLV 
carries the algorithm and hence there is no need to repeat in the Sub-TLV. This 
is not the case for SRv6 End.X SID Sub-TLV and hence it has the algorithm field.

Thanks,
Ketan

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Christian Hopps
Date: 2020-01-24 04:24
To: lsr
CC: 
draft-li-lsr-ospfv3-srv6-extensions;
 lsr-ads; Christian Hopps; 
Acee Lindem \(acee\)
Subject: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & Acee.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Please check inline again.

From: li_zhenqi...@hotmail.com 
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) ; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Thank you KT for your quick response. Please see my reply begins with [ZQ].

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 13:42
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to which the router can apply Penultimate
   Segment Pop (PSP) or Ultimate Segment Pop (USP)


NEW: The Maximum End Pop MSD Type specifies the maximum number of SIDs in

   the SRH for which the router can apply Penultimate

   Segment Pop (PSP) or Ultimate Segment Pop (USP)


[ZQ] Fine.

2. The abbreviations used in this draft should be listed in a seperated section 
or point out where they are defined.
[KT] We’ve followed the convention of expanding on first use as also providing 
reference where necessary. Please do let know if we’ve missed doing so anywhere.

[ZQ] Some examples: SPF computation in secction 5,  TBD in section 2.
[KT] Will expand SPF and some other such on first use :-). The TBD (to be 
decided) is for use until the code point are allocated by IANA.

3. Algorithm field is defined for End.x SID to carry the algorithm the end.x 
sid associates. But no algorithm field is defined for End SID in section 7. May 
I know the reason?
[KT] The SRv6 Locator TLV that is the parent of the SRv6 End SID Sub-TLV 
carries the algorithm and hence there is no need to repeat in the Sub-TLV. This 
is not the case for SRv6 End.X SID Sub-TLV and hence it has the algorithm field.


[ZQ] Make sense but still a little bit weird. Since any SID belongs to a 
locator, or it is not routable, the algorithm field in the end.x sid is not 
needed, end.x sid associates the algorithm carried in the corresponding locator 
tlv.

[KT] Having an algorithm field advertised with the End.X SID makes it easier 
for implementation to find the algorithm specific End.X SID without making the 
longest prefix match on all locators advertised by the node to find the 
algorithm to which the SID belongs. It also makes it possible to verify that 
the algorithm associated with the End.X SID matches that of the covering 
Locator when the link advertisement with End.X SID is received.



Thanks,

Ketan

Thanks,
Ketan

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Christian Hopps<mailto:cho...@chopps.org>
Date: 2020-01-24 04:24
To: lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem \(acee\)<mailto:a...@cisco.com>
Subject: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Thanks Acee. Your proposed text looks much better.

Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 31 January 2020 18:02
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hey Ketan, 

Looks good - but can we simplify/shorten the last sentence?


On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know 
if this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


How about  "... with the algorithm that will be used for computing paths 
destined to the SID."? 

Do we refer to "specific algorithm topologies" in the flex algorithm draft? I 
haven't read it for a while... 

Thanks,
Acee


Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
    To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. 
I don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was 
configured for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way 
of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't 
defined as the algorithm from the longest match locator. That way, everyone in 
>the area would use the same one and there would be less that could go wrong. 
What am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different 
algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along 
with the test for ignoring END.X SIDs that have conflicting algorithms with 
their longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
    >  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps 
, lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know if 
this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. I 
don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was configured 
for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't defined 
as the algorithm from the longest match locator. That way, everyone in >the 
area would use the same one and there would be less that could go wrong. What 
am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along with 
the test for ignoring END.X SIDs that have conflicting algorithms with their 
longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
>  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps , 
lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Acee/Zhen,
>  >
>  > The sec 8 of the draft has the following text which specifies the
>  > handling of this condition.
>  >
>  > All End.X SIDs MUST be subsumed by the subnet of a Locator 
with the
>  >
>  > matching algorithm which is advertised by the same node in an 
SRv6
>  >
>  > Locator TLV.  End.X SIDs which do not meet this requirement 
MUST be
>  >
>  > ignored.
>  >
>  > Thanks,
>  >
>  > Ketan
>  >
>  > *From:* Acee Lindem (acee) 
>  > *Sent:* 30 January 2020 21:01
>  > *To:* li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant)
>  > ; Christian Hopps ; lsr 

>  > *Cc:* draft-li-lsr-ospfv3-srv6-extensions
>  > ; lsr-ads 

>  > *Subject:* Re: [Lsr] WG Adoption Call for
>  >

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi All,

Support the draft as a co-author and I am not aware of any IPR other than what 
has been disclosed on this draft.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 24 January 2020 01:55
To: lsr@ietf.org
Cc: Christian Hopps ; Acee Lindem (acee) ; 
lsr-...@ietf.org; draft-li-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
 
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & Acee.

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

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Acee/Zhen,

The sec 8 of the draft has the following text which specifies the handling of 
this condition.

   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 30 January 2020 21:01
To: li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant) ; 
Christian Hopps ; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Ketan, Zhen,

What happens if there an algorithm conflict between the Adjacency END.X SID and 
the longest match Locator SID? Either one has to take precedence or this is an 
error condition. In either case, it needs to be documented.
Thanks,
Acee

From: "li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>" 
mailto:li_zhenqi...@hotmail.com>>
Date: Thursday, January 30, 2020 at 10:20 AM
To: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.com>>, 
Christian Hopps mailto:cho...@chopps.org>>, lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 lsr-ads mailto:lsr-...@ietf.org>>, Christian Hopps 
mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

For the third concern, I think it is better to list the considerations behind 
the format design of the TLVs to help readers understand them better. For the 
specification behavior you mention, this doc SHOULD specify it explicitly.
By the way, what a router should do when it receives END.X SID containing 
algorithm that is different from the one carried in the convering locator?

Best Regards,
Zhenqiang Li
____
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 16:44
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Please check inline again.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Thank you KT for your quick response. Please see my reply begins with [ZQ].

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 13:42
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to whic

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris/Acee,

The WG version of the draft has just been posted. It also includes the changes 
for the comments received during the adoption as discussed on the mailing list.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Christian Hopps  
Sent: 12 February 2020 16:42
To: lsr@ietf.org
Cc: Christian Hopps ; 
draft-li-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-...@ietf.org; Acee Lindem 
(acee) 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

The document is adopted.

Authors, please repost as draft-ietf-lsr-ospfv3-srv6-extensions.

Thanks,
Chris & Acee.

> On Jan 23, 2020, at 3:24 PM, Christian Hopps  wrote:
> 
> Hi LSR WG and Draft Authors,
> 
> The authors originally requested adoption back @ 105; however, some comments 
> were received and new version was produced. Moving forward...
> 
> This begins a 2 week WG adoption poll for the following draft:
> 
>  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
> 
> Please indicate your support or objection by Feb 6, 2020.
> 
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 

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

Re: [Lsr] Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

[Ketan Talaulikar (ketant)]

Hi Acee,

Thanks for your review, comments and suggestions. We’ve incorporated them and 
posted an update for this draft.

Note that as requested in a separate email thread, the draft has been renamed 
so it is associated with the LSR WG instead of the old OSPF one : 
https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/

This draft also has editorial changes to align with the latest version of the 
draft-ietf-spring-srv6-network-programming and is functionally equivalent to 
the draft-ietf-lsr-isis-srv6-extensions.

The authors believe this version is ready for WG adoption as requested 
previously.

Thanks,
Ketan (on behalf of co-authors)

From: Lizhenbin 
Sent: 16 December 2019 20:31
To: Acee Lindem (acee) ; 
draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: RE: Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

Hi Acee,
Thanks very much for your help to refine the draft. You suggestion also makes 
sense. We will update accordingly.

Best Regards,
Robin



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, December 13, 2019 5:44 AM
To: 
draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

Hi Robin, et al,
One thing I’d like to see is incorporation of the text for the MSD types in the 
draft. It is less than one and a half pages and it doesn’t make sense to 
reference the IS-IS draft. I’ve also attached my editorial comments.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Ketan Talaulikar (ketant)]

Support the publication

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 03 January 2020 00:37
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Antoni Przygienda 

Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for 
draft-ietf-lsr-isis-invalid-tlv.

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/

Tony P (other authors already responded during the adoption poll), please 
indicate your knowledge of any IPR related to this work to the list as well.

Thanks,
Chris & Acee.

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

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

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Thanks Chris. We've just posted the WG version of this draft that was adopted.

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 06 January 2020 23:49
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; 
draft-ketant-lsr-ospf-bfd-strict-m...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

That should be draft-ietf-lsr-ospf-bfd-strict-mode

Thanks,
Chris.

> On Jan 6, 2020, at 1:18 PM, Christian Hopps  wrote:
> 
> The document is adopted.
> 
> Authors, please repost with the name draft-lsr-ospf-bfd-strict-mode-00.
> 
> Thanks,
> Chris & Acee.
> 
>> On Dec 13, 2019, at 6:54 AM, Christian Hopps  wrote:
>> 
>> Hi LSR WG and Draft Authors,
>> 
>> This begins a 2 week WG adoption poll for the following draft:
>> 
>> https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/
>> 
>> Please indicate your support or objection by Dec 27th.
>> 
>> Authors, please respond indicating whether you are aware of any IPR that 
>> applies to this draft.
>> 
>> Thanks,
>> Chris & Acee.
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 

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

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

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

[Ketan Talaulikar (ketant)]

Thanks Chris. We've just posted the WG version of this draft that was adopted.

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 06 January 2020 23:51
To: lsr@ietf.org
Cc: draft-ketant-lsr-ospf-reverse-met...@ietf.org; lsr-...@ietf.org; Christian 
Hopps 
Subject: Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

The document is adopted.

Authors, please post a new version with name 
draft-ietf-lsr-ospf-reverse-metric-00.

Thanks,
Chris.

> On Dec 13, 2019, at 6:28 AM, Christian Hopps  wrote:
> 
> Hi LSR WG and Draft Authors,
> 
> This begins a 2 week WG adoption poll for the following draft:
> 
>  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reverse-metric/
> 
> Please indicate your support or objection by Dec 27th.
> 
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
> 
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 

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

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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

Dropping the draft-ietf-spring-srv6-network-programming authors since we are 
now back to discussing the ISIS extensions.

Please check inline below.

From: Chris Bowers 
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant) 
Cc: Ketan Talaulikar (ketant) ; lsr@ietf.org; SPRING WG List 
; draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 
; Bruno Decraene 
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

See inline [CB].

On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Chris,

You are right in that there is no assumption that all SRv6 locators in a domain 
are allocated from the same block. Therefore knowing the blocks used in the 
domain is useful.

[CB] Since you refer to "blocks" (plural) in this sentence, are you saying that 
in the scenario where all SRv6 locators in a domain are not allocated from the 
same block, you would expect different routers in the same domain to advertise 
different values of B and N?
[KT] While personally I believe it would not be the usual case, it is left to 
the operator.

For example, assume we have a network where all SRv6 locators in a domain are 
not allocated from the same block.  Router A advertises an SRv6 Locator TLV 
with locator = 2000::/64, and an SRv6 End SID sub-TLV with some endpoint 
behavior.  Router B advertises an SRv6 Locator TLV with locator = 3000::/64, 
and an SRv6 End SID sub-TLV with some endpoint behavior. What should routers A 
and B advertise as the values of B and N in their SRv6 SID Structure 
Sub-Sub-TLVs ?
[KT] It is difficult for me to figure out what the block and node parts are 
with such an addressing.


The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

[CB] If an ISIS speaker is not expected to do anything with B and N, then I 
think the text in draft-ietf-lsr-isis-srv6-extensions needs to clarify this.  I 
have a similar observation about Fun. Length and Arg. Length in the SRv6 SID 
Structure Sub-Sub-TLV .  As far as I can tell, none of the endpoint behaviors 
that are currently specified to be carried in ISIS End, End.X, and LAN End.X 
SIDs sub-TLVs uses an Argument, so there is never a case where an SRv6 SID 
Structure Sub-Sub-TLV should have a non-zero value for Arg. Length. What should 
an ISIS speaker do if it receives a non-zero value of the Arg. Length for an 
endpoint behavior that doesn't use an argument?  Are there any use cases 
envisioned where an ISIS speaker needs to know the Arg. Length ?
[KT] The behaviors currently listed in the draft do not have an argument nor is 
the use of B and N required for them. We cannot preclude a future use-case or 
extension where such behaviors introduced are also applicable to ISIS. So IMHO 
ruling such aspects out might not be the right thing to do from a protocol 
extensibility perspective.

Thanks,
Ketan

Thanks,
Ketan

From: Chris Bowers 
mailto:chrisbowers.i...@gmail.com>>
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Ketan Talaulikar (ketant) 
mailto:40cisco.@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Bruno 
Decraene mailto:bruno.decra...@orange.com>>
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

Based on current documents, allocating all SRv6 locators used in a domain from 
a single block is optional.

However, assuming for the moment that a network operator has chosen to allocate 
all SRv6 locators used in a domain from a single block, so that there is a 
well-defined value of B and N across a domain, what is the use of having a 
router advertise its own understanding of these two values?  And what is a 
receiver supposed to do with this information?

Thanks,
Chris

On Fri, Feb 28, 2020 at 8:23 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) 
[mailto:ket...@

Re: [Lsr] [spring] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

I've been following that thread 

IMHO it would depend on the nature of extension and seems not something that I 
would speculate about.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 12 March 2020 17:04
To: spr...@ietf.org
Cc: Chris Bowers ; lsr@ietf.org; Peter Psenak 
(ppsenak) ; Bruno Decraene 
Subject: Re: [Lsr] [spring] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions


Ketan Talaulikar (ketant)  writes:

> [KT] The behaviors currently listed in the draft do not have an argument nor 
> is the use of B and N required for them. We cannot preclude a future use-case 
> or extension where such behaviors introduced are also applicable to ISIS. So 
> IMHO ruling such aspects out might not be the right thing to do from a 
> protocol extensibility perspective.

No opinion here on this sub-sub-TLV; however, it has been stated elsewhere that 
this document will be re-spun for each new behavior that is to be carried in 
IS-IS (not my personal preference, fwiw...).

Thanks,
Chris.
[as WG member]
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

I am repeating the use-case described previously:
The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
We do carry information in the IGPs for propagation as part of the topology 
information for enabling use-cases outside the router (e.g. via BGP-LS). We do 
not need to preclude a use-case for it in IGPs themselves in the future.

Thanks,
Ketan

From: Chris Bowers 
Sent: 12 March 2020 20:29
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 

Cc: lsr@ietf.org; SPRING WG List ; Bruno Decraene 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Peter,

I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from 
draft-ietf-lsr-isis-srv6-extensions.  I think that we should leave the ability 
to include sub-sub-TLVs in the SRv6 End SID Sub-TLV, End.X SID Sub-TLV, and LAN 
End.X SID Sub-TLV in the encodings for those sub-TLVs.

I don't think that the current text describing the SRv6 SID Structure 
Sub-Sub-TLV would result in interoperable implementations.  Based on the 
discussion with Ketan below, it appears that use cases for ISIS speakers 
receiving advertised values of LB Length, LN Length, Fun. Length, and Arg. 
Length are not currently well-defined.So I think it makes sense to defer 
the definition of the SRv6 SID Structure Sub-Sub-TLV to a future document.

Thanks,
Chris

On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Chris,

Dropping the draft-ietf-spring-srv6-network-programming authors since we are 
now back to discussing the ISIS extensions.

Please check inline below.

From: Chris Bowers 
mailto:chrisbowers.i...@gmail.com>>
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Bruno 
Decraene mailto:bruno.decra...@orange.com>>
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

See inline [CB].

On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Chris,

You are right in that there is no assumption that all SRv6 locators in a domain 
are allocated from the same block. Therefore knowing the blocks used in the 
domain is useful.

[CB] Since you refer to "blocks" (plural) in this sentence, are you saying that 
in the scenario where all SRv6 locators in a domain are not allocated from the 
same block, you would expect different routers in the same domain to advertise 
different values of B and N?
[KT] While personally I believe it would not be the usual case, it is left to 
the operator.

For example, assume we have a network where all SRv6 locators in a domain are 
not allocated from the same block.  Router A advertises an SRv6 Locator TLV 
with locator = 2000::/64, and an SRv6 End SID sub-TLV with some endpoint 
behavior.  Router B advertises an SRv6 Locator TLV with locator = 3000::/64, 
and an SRv6 End SID sub-TLV with some endpoint behavior. What should routers A 
and B advertise as the values of B and N in their SRv6 SID Structure 
Sub-Sub-TLVs ?
[KT] It is difficult for me to figure out what the block and node parts are 
with such an addressing.


The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

[CB] If an ISIS speaker is not expected to do anything with B and N, then I 
think the

Re: [Lsr] draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

Hi Wang,

You are correct. Though I wouldn't call it a goal but rather a 
benefit/advantage - same applies to SR-MPLS where the label stack can be 
reduced.

Thanks,
Ketan

From: Lsr  On Behalf Of Wang, Weibin (NSB - CN/Shanghai)
Sent: 08 May 2020 19:07
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi authors:

After reading through this draft lsr-flex-algo, I want to know whether there is 
a potential goal of this draft to reduce the SRH size with enabling flex-algo 
with admin group in SRv6 deployment, because without flex-algo we have to have 
a big SRH size when the SRH include more SRv6 SIDs, if we enable flex-algo 
under special topology and link constraint condition, in theory we can even 
construct  a end to end SR path/tunnel without SRH, but it still meet TE 
requirement. So my question is whether the flex-algo can be used as tool to 
reduce SRH size?



Cheers !

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hello,

I support the progression to publication and as co-author, I am not aware of 
any undisclosed IPR.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 15 October 2020 11:45
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; lsr-...@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related to this 
work.

Thanks,
Chris.

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

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

I support the adoption of this document by the WG and as an author, I am not 
aware of any IPR associated with it.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 02 October 2020 17:33
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; 
draft-ketant-lsr-ospf-l2bundles@ietf.org
Subject: WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

Please indicate your support or objection by October 16, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

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

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your support and comments on the draft.

The proposed encoding for L2 Bundle members and their attributes in OSPF is 
different than the ISIS encodings in RFC8668. ISIS encodings have “tighter” LSP 
space considerations that OSPF. The authors have proposed a simpler encoding 
scheme for OSPF – feedback/inputs are welcome.

The list of attributes in Figure 2 and 3 also includes L2 Bundle member Adj 
SID. Since the encoding scheme is similar to Layer 3 attributes, we can re-use 
the same sub-TLVs.

Thanks,
Ketan

From: Lsr  On Behalf Of Gyan Mishra
Sent: 03 October 2020 04:07
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; draft-ketant-lsr-ospf-l2bundles@ietf.org; Christian Hopps 
; lsr-cha...@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01


I support WG adoption of this draft.

I agree that OSPF needs the functionality equivalent to that defined for IS-IS 
in RFC 8668.

I think the draft should include similar to RFC 8668 section 3 parallel layer 3 
adjacencies 3 similar Sub TLVs mentioned flag for multiple parallel adjacencies.

Also maybe section 4 of RFC 8668 would apply as well to ospf advertisement of 
L2 bundle Adj sid.

Thanks

Gyan

On Fri, Oct 2, 2020 at 6:11 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
I support WG adoption of this draft.

OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668.



   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Christian Hopps

> Sent: Friday, October 02, 2020 5:03 AM

> To: lsr@ietf.org

> Cc: lsr-cha...@ietf.org; Christian Hopps 
> mailto:cho...@chopps.org>>; draft-ketant-

> lsr-ospf-l2bundles@ietf.org

> Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

>

> This begins a 2 week WG adoption call for the following draft:

>

>   https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

>

> Please indicate your support or objection by October 16, 2020.

>

> Authors, please respond to the list indicating whether you are aware of any

> IPR that applies to this draft.

>

> Thanks,

> Chris and Acee.



___

Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/mailman/listinfo/lsr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your review and feedback. Please check inline below.

From: Gyan Mishra 
Sent: 16 October 2020 10:11
To: Aijun Wang 
Cc: Christian Hopps ; Jeff Tantsura 
; John E Drake ; 
Les Ginsberg (ginsberg) ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr@ietf.org; lsr-...@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

I support advancement of the draft.

This draft follows along the lines of ISIS RFC 7794 to provide an extension to 
identify the prefix originator attribute using an originating router TLV and a 
reachable prefix.  A node in ospf is represented by a router-id which 
technically can be a random 4 octet prefix that does not have to be reachable 
entry in the IGP RIB.

The reachability prefix is important in cases where the originator router-id is 
not  in the RIB or in traffic engineering inter as path instantiation use case 
where the router-id originator node is advertised, however since the TEDs 
database link attributes are not known inter-as,having the reachability address 
is important as defined in the draft.  This feature can also be used  
identifying the prefix originator in a normal user case other then the traffic 
engineering scenario such as for troubleshooting which is common to view all 
the prefixes advertised by a node by Prefix type.

There maybe cases where you need to create  a database filter or policy and if 
you can use this feature as a means of controlling prefix advertisements based 
on source node that can be powerful and could have ubiquitous use cases.

With regards to the appendix it does appear to be pertinent, as the use case 
appears to be the primary focal point and reason for the draft by the authors.  
I don’t think that having the appendix  precluding other use cases by any means.
[KT] The Introduction section of the draft does touch upon some of the primary 
use-cases that authors believe have more wide-spread applicability. You have 
also alluded to some of them and then you have also brought out some newer 
use-cases/applications of the extensions in this draft. There were other 
use-cases in previous versions like ELC which later went away based on how we 
addressed that in draft-ietf-ospf/isis-mpls-elc documents. I am sure there will 
be newer use-cases. The focus of the draft is primary to capture the protocol 
extensions since that is what we work on in LSR. The scope of the use-cases may 
be beyond LSR and in other areas (e.g. TEAS perhaps for the one in the appendix 
?). Regarding the use-case in the appendix, it would be fair to say that it was 
primary focal point for some of the authors.

I will leave it to the WG consensus on what content we should be sending to the 
IESG.

Thanks,
Ketan

Kind Regards

Gyan

On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Les, John and Jeff:

Let's reply you all together.
In my POV, The standard document should not define solely the protocol 
extension, but their usages in the network deployment. As I known, almost all 
the IETF documents following this style.
And, before adopting one work, we have often intense discussion for what's 
their usages.
Such discussion in the mail list and statements in the document can certainly 
assist the reader/user of the document get the essence of the standard, and 
follow them unambiguously.

Regarding the contents of appendices, as stated in the section, "The Appendix A 
heuristic to rebuild the topology can normally be used if all links are 
numbered." I think this can apply almost most of the operator's network, and 
facilitate the inter-area TE path calculation for central controller, or even 
for the head-end router that located in one area that different from the 
tail-end router.

Keeping the contents of appendices does not have the negative impact of the 
protocol extension, it is just one reference for the usage of this extension.
One can select not refer to it, if their networks are deployed with large 
amount of unnumbered links. But for others, the heuristic applies.

Best Regards

Aijun Wang
China Telecom



-Original Message-
From: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] On Behalf Of Jeff 
Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake 
mailto:40juniper@dmarc.ietf.org>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org; Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; lsr-...@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake 
> mailto:40juniper@dmarc.ietf.org>> 
> wrote:
>
> Hi,
>
> I agree with Les.  This is a simple protocol 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hi Baalajee,

Thanks for you review and comments. We’ll incorporate these 
fixes/clarifications in the upcoming update.

Thanks,
Ketan

From: Baalajee S (basurend) 
Sent: 20 October 2020 10:48
To: Christian Hopps ; lsr@ietf.org
Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; 
lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06


Hello authors,



I have a couple of comments.



1.
   A received Prefix Originator Sub-TLV that has an invalid length (not
   4 or 16) or a Reachable Address containing an invalid IPv4 or IPv6
   address (dependent on address family of the associated prefix) MUST
   be considered invalid and ignored.  Additionally, reception of such
   Sub-TLV SHOULD be logged as an error (subject to rate-limiting).


Shouldn’t that be “Router address”?


2.
   If the originating node is advertising an OSPFv2 Router Address TLV
   [RFC3630] or an OSPFv3 Router IPv6 
Address TLV [RFC5329], then that
   value is set in the Router Address field of the Prefix Originator
   Sub-TLV.  When the orignating node is not advertising such an



Wang, et al. Expires January 1, 2021[Page 5]


Internet-Draft  OSPF Prefix Originator Extensions  June 2020


   address, implementations MAY support mechanisms to determine a
   reachable address belonging to the originating node to set in the
   Router Address field.  Such mechanisms are outside the scope of this
   document.


Originating -> originating



I assume that the “Router address” picked by a router could be one of the 
addresses advertised by it with “N-bit” (Node SID) set or some other reachable 
address which uniquely identifies the router.



Regards,

S. Baalajee



On 15/10/20, 11:46 AM, "Lsr on behalf of Christian Hopps" 
mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20cho...@chopps.org>>
 wrote:



This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:



  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



The following IPR has been filed https://datatracker.ietf.org/ipr/3448/



Authors,



  Please indicate to the list, your knowledge of any other IPR related to 
this work.



Thanks,

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hi Chris/All,

We've just posted the v07 of the draft with the contentious appendix sections 
removed and also addressing some comments received on the list.

https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-07 

Thanks,
Ketan (on behalf on co-authors)

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 19 October 2020 22:37
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; John E Drake 
; Christian Hopps ; lsr-cha...@ietf.org; 
lsr@ietf.org; Jeff Tantsura ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06



> On Oct 16, 2020, at 4:47 AM, Aijun Wang  wrote:
> 
> Hi, Les and experts in LSR:
> 
> I am open to the removal of the this appendix to forward this draft.

That's good news, thank you Aijun.

Speaking for the chairs,

We believe we have reached WG consensus (seems better than just rough even with 
some authors asking for the change) at this point on the removal of the 
disputed use-case appendices.

Could you please republish the document w/o the disputed sections?

Thanks,
Chris.

> But as stated in previous mail, providing this can assist the user/reader of 
> the draft. We often encounter the questions in the mail list that what the 
> usage of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. The 
> description of this part is very concise.
> 
> If you insist this, I can update the draft in recent days, together with 
> other comments on this draft.
> 
> Other comments are welcome also!
> 
> Aijun Wang
> China Telecom
> 
>> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg)  
>> wrote:
>> 
>> Aijun -
>> 
>> The point I am making is very focused.
>> 
>> This draft is defining a protocol extension. As such it is necessary that 
>> this be Standards track as adhering to the normative statements in the draft 
>> are necessary for interoperability.
>> 
>> What is discussed in the Appendix is a use case. It is not normative and 
>> there are strong opinions on both sides as to whether this is an appropriate 
>> use case or not.
>> In the context of this draft, I have no interest in trying to resolve our 
>> difference of opinion on this use case. I simply want the protocol extension 
>> to move forward so that we have another tool available.
>> 
>> If you want to write a draft on the use case discussed in the Appendix 
>> please feel free to do so. That draft may very well not be normative - 
>> Informational or BCP may be more appropriate - because it will be discussing 
>> a deployment scenario and a proposal to use defined protocol extensions as 
>> one way to solve problems in that deployment scenario. Such a draft might 
>> also be more appropriate in another WG (e.g., TEAS). The merits of using 
>> prefix advertisements to build a topology could then be discussed on its own.
>> 
>> Please do not try to avoid having a full discussion of the merits of using 
>> prefix advertisements to derive topology by adding it to a draft that is 
>> (and should be) focused on simple protocol extensions.
>> 
>> Thanx.
>> 
>>  Les
>> 
>> 
>>> -Original Message-
>>> From: Aijun Wang 
>>> Sent: Thursday, October 15, 2020 6:51 PM
>>> To: 'Jeff Tantsura' ; 'John E Drake'
>>> 
>>> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les 
>>> Ginsberg
>>> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
>>> draft-ietf- lsr-ospf-prefix-origina...@ietf.org
>>> Subject: RE: [Lsr] WG Last Call 
>>> draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> Hi, Les, John and Jeff:
>>> 
>>> Let's reply you all together.
>>> In my POV, The standard document should not define solely the 
>>> protocol extension, but their usages in the network deployment. As I 
>>> known, almost all the IETF documents following this style.
>>> And, before adopting one work, we have often intense discussion for 
>>> what's their usages.
>>> Such discussion in the mail list and statements in the doc
> 

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

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

As a co-author, I am not aware of IPR beyond what has been already disclosed on 
this document.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 18 August 2020 05:00
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; Acee Lindem (acee) 
; draft-ietf-lsr-flex-algo@ietf.org
Subject: WG Last Call for draft-ietf-lsr-flex-algo

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.

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

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

Hi Thomas,

Thanks for your response. Let us also wait for inputs from others in the WGs.

One small bit.

[KT] By giving different types for OSPF and ISIS, is the intention to 
troubleshoot routing preference selection (done based on "admin distance" 
between protocol selection in RIB)?
Thomas> "admin distance" is one reason why one path is considered over another 
from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an 
examples, it is "sr-prefer" configuration option.
KT2> The proposal to extend IE46 will cover the "sr-prefer" scenario and 
indicate whether the forwarding is happening with SR or LDP label. IMHO OSPF SR 
vs ISIS SR is perhaps not as useful?

Also, from an operational perspective (looking holistically), we have LSP 
ping/trace tools specified for MPLS (including SR segments/labels) to 
verify/validate consistency between forwarding and control plane to determine 
which protocol/label is being used and lot's more details.

Thanks,
Ketan

From: thomas.g...@swisscom.com 
Sent: 18 August 2020 18:28
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

Thank you very much for the feedback.

[KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR 
Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types 
from RFC8402)? It's a simpler change to an existing element/field that makes it 
easier for routers, collectors and analysers?
Thomas> I am open to this approach to change IE46 to include segment types for 
RFC8402. I understand your concern to add additional fields. I would appreciate 
feedback from the wg if that is the path we like to go.

[KT] By giving different types for OSPF and ISIS, is the intention to 
troubleshoot routing preference selection (done based on "admin distance" 
between protocol selection in RIB)?
Thomas> "admin distance" is one reason why one path is considered over another 
from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an 
examples, it is "sr-prefer" configuration option.

[KT] From the document, I believe we are still talking only about the top of 
the stack label ...
Thomas> Correct

[KT] My point is why do we need to introduce another ElementID and why not use 
the existing Type 46 as suggested above?
Thomas> See feedback above.


[KT] To be clear, I am not talking from the POV of a specific implementation. 
Let me summarize my feedback and perspective:

  *   Carefully consider the addition of more control plane elements and 
nuances into IPFIX since they require all that additional context/information 
to be made available at the "layer" (or component) from where IPFIX picks this 
info (traditionally from the "FIB"). This added information should have a 
strong enough justification of benefit - e.g. How does difference between Adj 
SID and LAN Adj SID matter?  How relevant it is to determine if the SR 
signaling protocol is OSPF or ISIS?
  *   Try to add/extend existing elements/fields with just the right amount and 
sufficient information that is necessary for flow analysis. We need to note 
that there may be many more/other sources for "off-box enrichment" of flow 
information collected and perhaps not everything needs to be determined and 
reported by routers.

Thomas> Absolutely. I fully agree on your feedback. We need to have the minimum 
possible in order to have a clear view about the MPL-SR forwarding. Since IPFIX 
using UDP for transport, without the possibility of fragmentation, we need to 
be careful as well not to add many more dimension's/fields.

Best Wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Monday, August 17, 2020 8:51 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
ops...@ietf.org<mailto:ops...@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas,

Please check inline below.

From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
mailto:thomas.g...@swisscom.com>>
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
ops...@ietf.org<mailto:ops...@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,


  *   This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

To be precise, the existing MPLS Label Type identifier differentiates from LDP, 
RSVP-TE. Not the new SrSidType IPFIX IE being proposed.
[KT] Why not ext

Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

[Ketan Talaulikar (ketant)]

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.

The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).

I am not sure if that answers your question.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: 18 August 2020 23:06
To: Veerendranatha Reddy V 
; lsr@ietf.org
Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Veerendranath,

On 18/08/2020 16:40, Veerendranatha Reddy V wrote:
> Hi Authors, All,
> 
> OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to 
> distinguish between Intra and Inter Area scope prefixes.
> 
> Whether any restrictions to not to use Prefix Range TLV for 
> external/NSSA prefixes ?

I don't see how you can use OSPF Extended Prefix Range TLV for NSSA, the usage 
of OSPF Extended Prefix Range TLV has only been defined in the context of RFC 
8665.

thanks,
Peter


> 
> For External Prefixes, we can able to use  Prefix Range TLV  by using 
> LSA type (based on AS scope Opaque Type , so the TLV is for External
> Prefixes)
> 
> But If we need to use the Prefix Range TLV for NSSA prefixes (Type-7) 
> , which are in area scope, there is no flag/route-type field in this 
> TLV to distinguish between Intra or NSSA prefixes( as IA flag will not 
> be set anyway).
> 
> Thanks & Regards,
> 
> Veerendranath
> 

___
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] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

[Ketan Talaulikar (ketant)]

Hi Veerendranatha,

Please check inline below.

-Original Message-
From: Veerendranatha Reddy V 
 
Sent: 19 August 2020 10:03
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.
The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
   inter-area type.  An Area Border Router (ABR) that is
   advertising the OSPF Extended Prefix Range TLV between
   areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we 
need to set this flag. So that it indicates the prefixes are of inter area 
type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or 
intra-area" (think of it as somewhat equivalent of the D bit in ISIS when 
leaking across levels). That does not mean that the advertised mappings need to 
be used for only for intra or inter area prefixes respectively.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).
[V] If ASBR is part of NSSA, and if we redistributed Prefix SIDs learnt form 
other protocols or other instance of OSPF, and those prefixes are result of 
Range TLV  in that protocol, we can apply range in dest  ospf instance 
[KT] I do not follow above statement - can you please try to 
elaborate/re-phrase?

Thanks,
Ketan

Thanks & Regards,
Veerendranath


-Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: Tuesday, August 18, 2020 11:28 PM
To: Peter Psenak ; Veerendranatha Reddy V 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.

The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).

I am not sure if that answers your question.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: 18 August 2020 23:06
To: Veerendranatha Reddy V 
; lsr@ietf.org
Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Veerendranath,

On 18/08/2020 16:40, Veerendranatha Reddy V wrote:
> Hi Authors, All,
> 
> OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to 
> distinguish between Intra and Inter Area scope prefixes.
> 
> Whether any restrictions to not to use Prefix Range TLV for 
> external/NSSA prefixes ?

I don't see how you can use OSPF Extended Prefix Range TLV for NSSA, the usage 
of OSPF Extended Prefix Range TLV has only been defined in the context of RFC 
8665.

thanks,
Peter


> 
> For External Prefixes, we can able to use  Prefix Range TLV  by using 
> LSA type (based on AS scope Opaque Type , so the TLV is for External
> Prefixes)
> 
> But If we need to use the Prefix Range TLV for NSSA prefixes (Type-7) 
> , which are in area scope, there is no flag/route-type field in this 
> TLV to distinguish between Intra or NSSA prefixes( as IA flag will not 
> be set anyway).
> 
> Thanks & Regards,
> 
> Veerendranath
> 

___
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] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

Hi Thomas,

Please check inline below.

From: thomas.g...@swisscom.com 
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,


  *   This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

To be precise, the existing MPLS Label Type identifier differentiates from LDP, 
RSVP-TE. Not the new SrSidType IPFIX IE being proposed.
[KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR 
Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types 
from RFC8402)? It's a simpler change to an existing element/field that makes it 
easier for routers, collectors and analysers?


  *   What value is provided for IPFIX analysis if the SR Prefix SID was being 
signalled via OSPF or ISIS?

It is important to distinguish between intend and result.
[KT] By giving different types for OSPF and ISIS, is the intention to 
troubleshoot routing preference selection (done based on "admin distance" 
between protocol selection in RIB)?

If you migrate from one label distribution protocol to another, a network 
operator want's to understand if the data plane is still forwarding packets 
with the label distribution protocol which needs to be removed or not. IE46 
enables that by looking at the result of the forwarded traffic and not at the 
intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, 
describes the context.
[KT] Sure, so adding the SR Segments to IE46, one can check whether the traffic 
forwarding is happening using LDP or SR labels at any link in the network.



  *   What value is provided for IPFIX analysis if it was a Adjacency SID or a 
LAN Adjacency SID?

Quote from RFC8402. "Segment Routing (SR) leverages the source routing 
paradigm". Means that not the routing protocol does all the forwarding 
decisions, the node can change the forwarding by pushing additional labels.
[KT] From the document, I believe we are still talking only about the top of 
the stack label ...

With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to 
analyze the result of this decision. The example with " Adjacency SID or a LAN 
Adjacency SID" is not very useful because the difference of the two is the 
topology among the adjacency. If you compare " Adjacency SID with Prefix SID", 
that makes much more sense. Since it describes that a particular adjacency is 
chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is 
drop, we understand that result of that decision lead to the drop and this 
enables to narrow down forwarding issues in segment routing networks more 
efficiently and quickly.
[KT] My point is why do we need to introduce another ElementID and why not use 
the existing Type 46 as suggested above?


  *   am asking for WG to weigh the implementation complexities

For the WG and me, I would be important if you can describe more detailed what 
you mean with implementation complexities. I would like to have a better 
understanding where your fear is coming from. I would appreciate if you could 
differentiate between MPLS Label Type identifier, IE46, from which label 
protocol the label was coming from and SrSidType which SID type was used..
[KT] To be clear, I am not talking from the POV of a specific implementation. 
Let me summarize my feedback and perspective:

  *   Carefully consider the addition of more control plane elements and 
nuances into IPFIX since they require all that additional context/information 
to be made available at the "layer" (or component) from where IPFIX picks this 
info (traditionally from the "FIB"). This added information should have a 
strong enough justification of benefit - e.g. How does difference between Adj 
SID and LAN Adj SID matter?  How relevant it is to determine if the SR 
signaling protocol is OSPF or ISIS?
  *   Try to add/extend existing elements/fields with just the right amount and 
sufficient information that is necessary for flow analysis. We need to note 
that there may be many more/other sources for "off-box enrichment" of flow 
information collected and perhaps not everything needs to be determined and 
reported by routers.

Thanks,
Ketan

Best wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
ops...@ietf.org<mailto:ops...@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas,

I should have been more clear in my email.

The proposal/suggestion is to add the following to the IPFIX MPLS Label type 
iden

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

< also copying Spring WG for their review/inputs >

Hi Thomas/All,

I have reviewed the draft and would like to share a different perspective.

What or how much value be there on determining whether a SR Prefix SID was 
signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is 
more important is that it is a Prefix SID. Hardly any deployments would be 
running multiple protocols and learning the same prefix from different IGPs. 
IPFIX may be picking this information from a FIB in some implementation where 
the protocol does not matter and this information is not available therein.

On some nodes, the same Prefix SID may be learnt via both BGP and IGP - what 
would we use/show?

I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP 
Peering SID and so on ... for the MPLS Label Type.

This also takes away the need for the second table that is being proposed to a 
large extent. For that table proposal, it is very difficult and in some cases 
not possible to different between Prefix and Node and Anycast SID. Many of 
these types are control plane elements and we can be sure more get added. Is 
there really much value in differentiation between say an Adjacency SID and LAN 
Adjacency SID?

Could we evaluate the implementation overhead and complexity of this level of 
categorization/information in IPFIX against their value in flow analysis to 
perhaps consider a middle ground?

Thanks,
Ketan

From: Lsr  On Behalf Of thomas.g...@swisscom.com
Sent: 31 July 2020 20:52
To: han...@gredler.at
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Hannes,

Thanks a lot for the feedback. Yes, makes completely sense. Will take it for 
the next update..

Best Wishes
Thomas


From: Hannes Gredler mailto:han...@gredler.at>>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Thomas,

I have one comment/suggestion to Paragraph 4 (IANA Considerations).

Please add also a code point for BGP Prefix-SID - it's quite popular in DC 
deployments.
https://tools.ietf.org/html/rfc8669

thanks,

/hannes

On 28.07.2020, at 10:11, 
thomas.g...@swisscom.com wrote:

Dear lsr,

I presented the following draft

Export of MPLS Segment Routing Label Type Information in IP Flow Information 
Export (IPFIX)
https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04

at the spring working group at IETF 108 yesterday
https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf

and today at OPSAWG where I call for adoption.

This draft adds additional segment routing code points for in the IANA IPFIX 
registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain 
further insights into the MPLS-SR forwarding-plane.

I have been asked to not only gather feedback from spring and opsawg but also 
from lsr and mpls working groups since these code points are related to link 
state routing protocols and mpls data plane.

I am looking forward to your feedback and input.

Best Wishes
Thomas Graf
___
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] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

Hi Thomas,

I should have been more clear in my email.

The proposal/suggestion is to add the following to the IPFIX MPLS Label type 
identifier registry:

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

And my questions were:

  1.  What value is provided for IPFIX analysis if the SR Prefix SID was being 
signalled via OSPF or ISIS?
  2.  What value is provided for IPFIX analysis if it was a Adjacency SID or a 
LAN Adjacency SID?

I am asking for WG to weigh the implementation complexities and overheads with 
the proposed details of SR-MPLS segments in IPFIX against the benefit (if any) 
that they provide for the flow analysis and monitoring.

Thanks,
Ketan

From: thomas.g...@swisscom.com 
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

Thank you very much for the review and feedback.


  *   What or how much value be there on determining whether a SR Prefix SID 
was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is 
more important is that it is a Prefix SID. Hardly any deployments would be 
running multiple protocols and learning the same prefix from different IGPs.

As Jeff already pointed out. Multiple IGP labelling protocols are used  in 
networks when migrations are ongoing. Usually in a life cycle. Migrating from 
LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom when we 
first discovered this shortcoming in vendor implementations. The key point 
here, with these additional IPFIX MPLS Label Type identifiers we enable the 
possibility to verify the label protocol migration without taking the label 
value into the consideration.


  *   IPFIX may be picking this information from a FIB in some implementation 
where the protocol does not matter and this information is not available 
therein.

I am not sure if you have seen the presentation in IETF 108 at OPSAWG and 
SPRING.
https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf

Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label Type 
identifier. There is an open ddts where vendor feasibility has been clarified. 
Ping me off the list when you like to have more details.

I do understand your point that not all the vendors are capable to implement IE 
46. But that's not the point about the IPFIX IE registry. The IE registry 
enables that an IPFIX implementation can refer to the right code point. With 
RFC 5102 the decision has been made that MPLS Label Type identifier make sense 
and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends the 
IE 46 registry with the Segment Routing label protocol code points so when 
OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX 
implementation can point to the right code point.


  *   On some nodes, the same Prefix SID may be learnt via both BGP and IGP - 
what would we use/show?

In this case the IE 46 shows the label protocol which was used to program the 
FIB.


  *   For that table proposal, it is very difficult and in some cases not 
possible to different between Prefix and Node and Anycast SID. Many of these 
types are control plane elements and we can be sure more get added.

I fully agree. As a network operator its still hard to understand the 
architecture and constraints within a router. When monitoring capabilities are 
discussed at IETF, this is the usual topic. What is possible, what make sense. 
By purpose, all available SID types are listed in the draft. This with the aim 
to start the discussion in the working groups what is possible what makes 
sense. I would be interested to get your and also Jeff's feedback.

In above mentioned slides I described how TI-LFA application would benefit of 
visibility in the FIB by showing where Adj-SID was used. This should be a 
simple example why it make sense not only to look at which label protocol was 
used to forward a particular packet, but also which SID type to further 
understand the intend why this label is being pushed.

I hope this makes all sense. Looking forward for reply.

Best wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG 
mailto:spr...@ietf.org>>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

< also copying Spring WG for their review/inputs >

Hi Thomas/All,

I have reviewed the draft and would like to share a different perspective.

What or how much value be there on determining whether a SR 

Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

[Ketan Talaulikar (ketant)]

Hi Veerendranatha,

Please check inline below with [KT2]

-Original Message-
From: Veerendranatha Reddy V 
 
Sent: 19 August 2020 13:07
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
   inter-area type.  An Area Border Router (ABR) that is
   advertising the OSPF Extended Prefix Range TLV between
   areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we 
need to set this flag. So that it indicates the prefixes are of inter area 
type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or 
intra-area" (think of it as somewhat equivalent of the D bit in ISIS when 
leaking across levels). That does not mean that the advertised mappings need to 
be used for only for intra or inter area prefixes respectively.
[V] When we receive the range TLV received at ABR, while it is originating 
opaque LSA for that range TLV across the other areas, whether it is required to 
set IA or not?
[KT2] Yes - please check the RFC8665 Sec 4 - right after where the IA flag is 
described. 

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).
[V] If ASBR is part of NSSA, and if we redistributed Prefix SIDs learnt form 
other protocols or other instance of OSPF, and those prefixes are result of 
Range TLV  in that protocol, we can apply range in dest  ospf instance 
[KT] I do not follow above statement - can you please try to 
elaborate/re-phrase?
[V] When redistributing  Prefix SID information to NSSA from other protocols , 
it may possible to generate Range TLV, if multiple prefixes can be aggregated 
as range., instead of generating extended Prefix TLV for each prefix. So while 
originating this range TLV, how we can differentiate whether it is intra Scope 
or NSSA scope. So that when it is received at ABR, he will consider to 
translate to inter area Opaque or External Opaque for that range.
[KT2] I believe Peter answered and clarified this part. There is no notion of 
NSSA area or NSSA-scope flooding for the Extended Prefix Range TLV. 

Thanks,
Ketan 

Thanks & Regards,
Veerendranath



-Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: Wednesday, August 19, 2020 10:27 AM
To: Veerendranatha Reddy V ; Peter Psenak 
(ppsenak) ; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Veerendranatha,

Please check inline below.

-Original Message-
From: Veerendranatha Reddy V 

Sent: 19 August 2020 10:03
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.
The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
   inter-area type.  An Area Border Router (ABR) that is
   advertising the OSPF Extended Prefix Range TLV between
   areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we 
need to set this flag. So that it indicates the prefixes are of inter area 
type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or 
intra-area" (think of it as somewhat equivalent of the D bit in ISIS when 
leaking across levels). That does not mean that the advertised mappings need to 
be used for only for intra or inter area prefixes respectively.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

[Ketan Talaulikar (ketant)]

Hi Joel,

Please check inline below.

-Original Message-
From: Lsr  On Behalf Of Joel M. Halpern
Sent: 25 September 2020 03:18
To: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

First, there is a slight confusion in the way I formed the quesiton, but I 
think it still applies.

The piece of this draft is section 9, which advertises the length of the arg 
portion of the SID.  But does not provide specific meanings for specific values.
[KT] This is quite appropriate for this draft since it is only specifying a 
generic SID structure and not associated with any specific behavior.

The example of an ARG in the network programming draft does provide part of the 
explicit interpretation of the ARG.  It says that it is a list of k items, each 
of x bits, where each x bit blob identifies an OIF.
[KT] The net-pgm draft in sec 4.12 introduces a specific End.DT2M behavior 
which includes support for ARG. That said, I am not quite sure about that text 
in that section which talks about how the ARG bits are formed and what they 
signify. I believe the ARG in this case is a locally assigned identifier that 
maps to an ESI so that it can be used for ESI filtering - much the same as an 
ESI label for split-horizon filtering. I see a comment from one of the ADs on 
this and I expect that the authors will clarify.

This leaves two gaps, and a more general question.
1) How does the receiver know the meanings of the OIF indices so that he can 
correctly fill them in?
2) The NP draft says that k and x are defined on a per SID basis.  But I do not 
see anywhere in the isis draft to advertise the values of k and x, only arg 
(which is k*x).
[KT] I hope the previous comment explains.

The more general question is, is there a requirement we can write down about 
how receivers will be able to understand ARG fields in general? 
One can argue that it would belong in the network programming draft; I would 
prefer not to delay that with a significant technical addition.
[KT] I don't believe the handling of ARG is something that can be generalized. 
It has to be something specific to the behavior that it is associated with. 
Therefore, each behavior that supports an ARG needs to specify its handling. 
The net-pgm draft is doing it for End.DT2M and future documents that introduce 
other behaviors requiring ARG would be expected to the same.

Thanks,
Ketan

There is a related question that I came across while trying to explain this 
question.

END.T must be associated with a forwarding table.  I presume this is done by 
where one puts the END.T (however-many-subs) TLV.  But I can not find anything 
in this draft that says this.  There is precisely one reference to End.T in the 
draft.

Thank you,
Joel

On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote:
> H Joel,
> 
> Can you reference the specific section in the IS-IS SRv6 draft you are 
> commenting on? I seem to remember this discussion but it was at least a month 
> back, if not more.
> 
> Thanks,
> Acee
> 
> On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern"  on behalf of j...@joelhalpern.com> wrote:
> 
>  The announcement prompted me to look again and think about an
>  interaction between this and the network programming draft.  To be
>  clear, I am NOT objecting to either this or the network programming
>  draft.  I am just wondering what I am missing.
> 
>  The NP draft, and the advertisement mechanism allows a router to
>  advertise the number of bits for the ARG portion of a SID.
> 
>  Q1: The point presumably is to avoid needing to advertise each of the
>  individual values?
> 
>  An example of this is, I think, and ARG for the table selection where
>  the ARG is the table number for the packet to be looked up in?
> 
>  Q2: If so, how does the head end know what table number corresponds to
>  what meaning?If this requires a separate advertisement there seems
>  to be no savings.  if this requires out-of-band knowledge then we seem
>  to have lost the benefit of advertising all of this in the routing 
> protocol.
> 
>  I suspect I am simply missing a piece.  can someone explain please?
> 
>  Thank you,
>  Joel
> 
>  On 9/23/2020 4:40 PM, internet-dra...@ietf.org wrote:
>  >
>  > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  > This draft is a work item of the Link State Routing WG of the IETF.
>  >
>  >  Title   : IS-IS Extension to Support Segment Routing 
> over IPv6 Dataplane
>  >  Authors : Peter Psenak
>  >Clarence Filsfils
>  >Ahmed Bashandy
>  >Bruno Decraene
>  >Zhibo Hu
>  >Filename: draft-ietf-lsr-isis-srv6-extensions-10.txt
>  >Pages   : 25
>  >Date   

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

[Ketan Talaulikar (ketant)]

Hi Joel,

Please check inline below.

-Original Message-
From: Lsr  On Behalf Of Joel M. Halpern
Sent: 25 September 2020 19:08
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

Thanks Ketan.  Let me paraphrase to confirm I understand, with some 
suggestions.  And repeat the last question which seems to have gotten lost.

It seems that you are saying that the arg field is defined for now so the 
format is consistent, but is not used by any behavior defined in this draft.
[KT] The ISIS draft does not actually define any behavior - it only specifies 
signaling of a subset of behaviors defined in net-pgm. You are right that the 
behaviors that are listed as being signalled by ISIS in the current document do 
not support an ARG.

If so, should we say explicitly that ARG is (or MUST be) 0 for all the 
behaviors defined in this draft?
[KT] I am not sure it is necessary. A future ISIS extension may introduce 
support for signaling of a behavior that supports ARG.

Then separately the folks working on the END.DT2M behavior can write their own 
draft one how to advertise that in is-is?  Presumably with an additional 
sub-TLV dealing with k and x?
[KT] End.DT2M is signaled in BGP and specified in BGP extensions. If a future 
ISIS extension was to advertise a SID with a behavior supporting ARG, then it 
would need to clarify its handling of the ARG.

Also, can you tell me how the association of an END.T behavior with a table is 
understood from the advertisement as described in the draft?
[KT] Indeed, the End.T signaling does not carry the table context with it. 

Thanks,
Ketan

Thank you,
Joel

On 9/25/2020 1:39 AM, Ketan Talaulikar (ketant) wrote:
> Hi Joel,
> 
> Please check inline below.
> 
> -Original Message-
> From: Lsr  On Behalf Of Joel M. Halpern
> Sent: 25 September 2020 03:18
> To: Acee Lindem (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: 
> draft-ietf-lsr-isis-srv6-extensions-10.txt
> 
> First, there is a slight confusion in the way I formed the quesiton, but I 
> think it still applies.
> 
> The piece of this draft is section 9, which advertises the length of the arg 
> portion of the SID.  But does not provide specific meanings for specific 
> values.
> [KT] This is quite appropriate for this draft since it is only specifying a 
> generic SID structure and not associated with any specific behavior.
> 
> The example of an ARG in the network programming draft does provide part of 
> the explicit interpretation of the ARG.  It says that it is a list of k 
> items, each of x bits, where each x bit blob identifies an OIF.
> [KT] The net-pgm draft in sec 4.12 introduces a specific End.DT2M behavior 
> which includes support for ARG. That said, I am not quite sure about that 
> text in that section which talks about how the ARG bits are formed and what 
> they signify. I believe the ARG in this case is a locally assigned identifier 
> that maps to an ESI so that it can be used for ESI filtering - much the same 
> as an ESI label for split-horizon filtering. I see a comment from one of the 
> ADs on this and I expect that the authors will clarify.
> 
> This leaves two gaps, and a more general question.
> 1) How does the receiver know the meanings of the OIF indices so that he can 
> correctly fill them in?
> 2) The NP draft says that k and x are defined on a per SID basis.  But I do 
> not see anywhere in the isis draft to advertise the values of k and x, only 
> arg (which is k*x).
> [KT] I hope the previous comment explains.
> 
> The more general question is, is there a requirement we can write down about 
> how receivers will be able to understand ARG fields in general?
> One can argue that it would belong in the network programming draft; I would 
> prefer not to delay that with a significant technical addition.
> [KT] I don't believe the handling of ARG is something that can be 
> generalized. It has to be something specific to the behavior that it is 
> associated with. Therefore, each behavior that supports an ARG needs to 
> specify its handling. The net-pgm draft is doing it for End.DT2M and future 
> documents that introduce other behaviors requiring ARG would be expected to 
> the same.
> 
> Thanks,
> Ketan
> 
> There is a related question that I came across while trying to explain this 
> question.
> 
> END.T must be associated with a forwarding table.  I presume this is done by 
> where one puts the END.T (however-many-subs) TLV.  But I can not find 
> anything in this draft that says this.  There is precisely one reference to 
> End.T in the draft.
> 
> Thank you,
> Joel
> 
> On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote:
>> H Joel,
>>
>> Can you reference the specific section in t

Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

[Ketan Talaulikar (ketant)]

I am not aware of any IPR other than the one already disclosed below.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 02 October 2020 01:54
To: draft-ietf-lsr-flex-a...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

Authors,

The following IPR has been disclosed (excerpted from 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo):

Date
ID
Statement
2018-08-08
3248
Cisco's Statement about IPR related to 
draft-ietf-lsr-flex-algo
2019-12-05
3910
Huawei Technologies Co.,Ltd's Statement about IPR related to 
draft-ietf-lsr-flex-algo


Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt

[Ketan Talaulikar (ketant)]

Hi All,

This is mostly a refresh with editorial updates. We look forward to review and 
feedback.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 30 June 2020 14:20
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Strict-Mode for BFD
Authors : Ketan Talaulikar
  Peter Psenak
  Albert Fu
  Rajesh M
Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
Pages   : 10
Date: 2020-06-30

Abstract:
   This document specifies the extensions to OSPF that enable an OSPF
   router to signal the requirement for a Bidirectional Forwarding
   Detection (BFD) session prior to adjacency formation.  Link-Local
   Signaling (LLS) is used to advertise this requirement of "strict-
   mode" of BFD session establishment for OSPF adjacency.  If both OSPF
   neighbors advertise the "strict-mode" of BFD, adjacency formation
   will be blocked until a BFD session has been successfully
   established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-01


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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] I-D Action: draft-ietf-lsr-ospf-prefix-originator-06.txt

[Ketan Talaulikar (ketant)]

Hi All,

We've recently submitted an update to this draft with the following changes:

1)  Introduced a new Prefix Originator Sub-TLV for carrying the reachable 
address of the node originating the prefix advertisement. This is equivalent to 
the similar ISIS extension - https://tools.ietf.org/html/rfc7794#section-2.2.
2) Removed the text related to use-case/justification for ELC since that no 
longer applies now with the updated IGP ELC drafts where this capability is now 
advertised as a prefix attribute. 
3) Removed references to ERLD and MSD since the originator node is the 
destination and not the transit or ingress for the flows towards the specific 
prefix.
4) Moved some remaining topology reconstruction use-case related text into the 
Appendix since it is non-normative.
5) Clarified and updated the procedures with normative text describing the 
origination of the sub-TLVs in more detail.
6) Other minor editorial changes.

Look forward to the WG review and feedback on this.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 30 June 2020 13:59
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-originator-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Prefix Originator Extensions
Authors : Aijun Wang
  Acee Lindem
  Jie Dong
  Peter Psenak
  Ketan Talaulikar
Filename: draft-ietf-lsr-ospf-prefix-originator-06.txt
Pages   : 11
Date: 2020-06-30

Abstract:
   This document defines OSPF extensions to include information
   associated with the node originating a prefix along with the prefix
   advertisement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-prefix-originator-06


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[Lsr] IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Hello Acee/Chris,

The authors would like to request IANA early allocations for this draft.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Ketan Talaulikar (ketant) 
Sent: 30 June 2020 14:25
To: lsr@ietf.org
Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt

Hi All,

This is mostly a refresh with editorial updates. We look forward to review and 
feedback.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 30 June 2020 14:20
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Strict-Mode for BFD
Authors : Ketan Talaulikar
  Peter Psenak
  Albert Fu
  Rajesh M
Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
Pages   : 10
Date: 2020-06-30

Abstract:
   This document specifies the extensions to OSPF that enable an OSPF
   router to signal the requirement for a Bidirectional Forwarding
   Detection (BFD) session prior to adjacency formation.  Link-Local
   Signaling (LLS) is used to advertise this requirement of "strict-
   mode" of BFD session establishment for OSPF adjacency.  If both OSPF
   neighbors advertise the "strict-mode" of BFD, adjacency formation
   will be blocked until a BFD session has been successfully
   established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-01


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[Lsr] WG adoption request for draft-ketant-lsr-ospf-l2bundles

[Ketan Talaulikar (ketant)]

Hello Acee/Chris,

Would like to request for WG adoption for 
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ 

The draft was presented at IETF 105 and has not changed much since then. There 
have been requests from operators using OSPF to provide the equivalent 
functionality as RFC8668 provided for IS-IS.

Thanks,
Ketan

-Original Message-
From: internet-dra...@ietf.org  
Sent: 30 June 2020 20:01
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 

Subject: New Version Notification for draft-ketant-lsr-ospf-l2bundles-02.txt


A new version of I-D, draft-ketant-lsr-ospf-l2bundles-02.txt
has been successfully submitted by Ketan Talaulikar and posted to the IETF 
repository.

Name:   draft-ketant-lsr-ospf-l2bundles
Revision:   02
Title:  Advertising L2 Bundle Member Link Attributes in OSPF
Document date:  2020-06-30
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-ketant-lsr-ospf-l2bundles-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/
Htmlized:   https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-l2bundles
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ketant-lsr-ospf-l2bundles-02

Abstract:
   There are deployments where the Layer 3 interface on which OSPF
   operates is a Layer 2 interface bundle.  Existing OSPF advertisements
   only support advertising link attributes of the Layer 3 interface.
   If entities external to OSPF wish to control traffic flows on the
   individual physical links which comprise the Layer 2 interface bundle
   link attribute information about the bundle members is required.

   This document introduces the ability for OSPF to advertise the link
   attributes of layer 2 (L2) Bundle members.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Hi Amanda/All,

I thought that there was an agreement to assign bit 0x0010 for 
draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for 
draft-ietf-lsr-dynamic-flooding?

Thanks,
Ketan

-Original Message-
From: Amanda Baber via RT  
Sent: 04 July 2020 07:53
To: Acee Lindem (acee) 
Cc: Peter Psenak (ppsenak) ; mraj...@juniper.net; 
lsr@ietf.org; Ketan Talaulikar (ketant) ; 
gunter.van_de_ve...@nokia.com; aretana.i...@gmail.com; 
alvaro.ret...@futurewei.com; acee=40cisco@dmarc.ietf.org
Subject: [IANA #1173602] Re: IANA early allocation request for 
draft-ietf-lsr-ospf-bfd-strict-mode

Hi Peter, all,

> > For both Peter and Gunter: the Flooding Request bit registration is 
> > described in the registry as a temporary allocation, but this may 
> > have been an mistake The RFC 7120 temporary early allocation 
> > procedure is meant for registries that require RFC publication for 
> > permanent registration. In theory, if the experts agree, permanent 
> > registrations can be made in Expert Review registries at any time.
> > Would there be an issue with removing the "TEMPORARY" designation 
> > from that registration?
> 
> please go ahead and remove the TEMPORARY.

The "TEMPORARY" designation has been removed from the 
draft-ietf-lsr-dynamic-flooding registration in LLS Type 1 Extended Options and 
Flags, currently still assigned 0x0010:

https://www.iana.org/assignments/ospf-lls-tlvs

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

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

+1

-Original Message-
From: Peter Psenak  
Sent: 02 July 2020 13:11
To: Acee Lindem (acee) ; iana-prot-pa...@iana.org
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) ; 
gunter.van_de_ve...@nokia.com; alvaro.ret...@futurewei.com
Subject: Re: [IANA #1173602] Re: IANA early allocation request for 
draft-ietf-lsr-ospf-bfd-strict-mode

Hi Ketan, Acee,

On 01/07/2020 23:24, Acee Lindem (acee) wrote:
> Hi Amanda,
> 
> On 7/1/20, 5:10 PM, "Amanda Baber via RT"  wrote:
> 
>  Hi Acee, Alvaro, all,
> 
>  Alvaro: can you approve the request for early registration of the B-bit 
> in the LLS Type 1 Extended Options and Flags registry at 
> https://www.iana.org/assignments/ospf-lls-tlvs?
> 
>  Acee, Ketan: the document says that it's registering 0x0010, but 
> that value was allocated to draft-ietf-lsr-dynamic-flooding last year. If 
> Alvaro approves, should we register 0x0020 instead?

I doubt there is any OSPF implementation of draft-ietf-lsr-dynamic-flooding, so 
it may be safer to use the
0x0010 for draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for 
draft-ietf-lsr-dynamic-flooding.

thanks,
Peter

> 
> Yes. While a few implementations have the BFD strict-mode configuration, I 
> don't believe any have shipped the LLS signaling yet.
> 
>  Acee, Ketan, Gunter, Peter: because it's using a different registration 
> procedure, I'm creating a separate ticket for the Link Local Signalling TLV 
> Identifiers (LLS Types) registration. I'll send an expert review request from 
> that ticket.
> 
> Fine - Thanks,
> Acee
> 
>  Best regards,
> 
>  Amanda Baber
>  Lead IANA Services Specialist
> 
>  On Wed Jul 01 19:38:00 2020, a...@cisco.com wrote:
>  > Hi Ketan,  IANA, Alvaro,
>  > I don't see any problem with early allocation of this LLS bit and TLV
>  > - pretty straight forward. It would make sense to put the respective
>  > registries in the IANA section (included below for info).
>  >
>  > Open Shortest Path First (OSPF) Link Local Signalling (LLS) -
>  > Type/Length/Value Identifiers (TLV)
>  >   Link Local Signalling TLV Identifiers (LLS Types) RFC 5613
>  >   IETF Review
>  >   LLS Type 1 Extended Options and Flags RFC 5613
>  >  Expert Review (Expert: Gunter Van De Velde, Peter Psenak)
>  >
>  > For the flag, the designated experts are Gunter and Peter (copied).
>  >
>  > Please initiate the early allocation process pending expert and AD
>  > approval.
>  > Thanks,
>  > Acee
>  >
>  > On 6/30/20, 4:58 AM, "Ketan Talaulikar (ketant)" 
>  > wrote: ts
>  >
>  > Hello Acee/Chris,
>  >
>  > The authors would like to request IANA early allocations for this
>  > draft.
>  >
>  > Thanks,
>  > Ketan (on behalf of co-authors)
>  >
>  > -Original Message-
>  >  From: Ketan Talaulikar (ketant)
>  > Sent: 30 June 2020 14:25
>  > To: lsr@ietf.org
>  > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-
>  > 01.txt
>  >
>  > Hi All,
>  >
>  > This is mostly a refresh with editorial updates. We look forward to
>  > review and feedback.
>  >
>  > Thanks,
>  > Ketan (on behalf of co-authors)
>  >
>  > -Original Message-
>  > From: Lsr  On Behalf Of internet-dra...@ietf.org
>  > Sent: 30 June 2020 14:20
>  > To: i-d-annou...@ietf.org
>  > Cc: lsr@ietf.org
>  > Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
>  >
>  >
>  > A New Internet-Draft is available from the on-line Internet-Drafts
>  > directories.
>  > This draft is a work item of the Link State Routing WG of the IETF.
>  >
>  > Title   : OSPF Strict-Mode for BFD
>  > Authors : Ketan Talaulikar
>  >   Peter Psenak
>  >   Albert Fu
>  >   Rajesh M
>  > Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
>  > Pages   : 10
>  > Date: 2020-06-30
>  >
>  > Abstract:
>  >This document specifies the extensions to OSPF that enable an OSPF
>  >router to signal the requirement for a Bidirectional Forwarding
>  >Detection (BFD) session prior to adjacency formation.  Link-Local
>  >Signaling (LLS) is used to advertise this requirement o

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Thanks Amanda.

-Original Message-
From: Lsr  On Behalf Of Amanda Baber via RT
Sent: 09 July 2020 01:37
To: Acee Lindem (acee) 
Cc: alvaro.ret...@futurewei.com; Ketan Talaulikar (ketant) ; 
gunter.van_de_ve...@nokia.com; mraj...@juniper.net; 
acee=40cisco@dmarc.ietf.org; lsr@ietf.org; aretana.i...@gmail.com; Peter 
Psenak (ppsenak) 
Subject: [Lsr] [IANA #1173602] Re: IANA early allocation request for 
draft-ietf-lsr-ospf-bfd-strict-mode

Hi Peter, Ketan, Acee, 

We've added a permanent entry for B-bit in the LLS Type 1 Extended Options and 
Flags registry and moved the Flooding Request bit registration to 0x0020:

0x0010  B-bit   [draft-ietf-lsr-ospf-bfd-strict-mode-01]
0x0020  Flooding Request bit[draft-ietf-lsr-dynamic-flooding]

Please see
https://www.iana.org/assignments/ospf-lls-tlvs

Best regards,

Amanda Baber
Lead IANA Services Specialist

On Wed Jul 08 08:53:07 2020, ppse...@cisco.com wrote:
> Amanda,
> 
> On 07/07/2020 22:54, Amanda Baber via RT wrote:
> > Peter, should we go ahead?
> 
> yes, please.
> 
> thanks,
> Peter
> 
> > 
> > thanks,
> > Amanda
> > 
> > On Tue Jul 07 20:14:48 2020, a...@cisco.com wrote:
> >> Gunter is on vacation...
> >> Thanks,
> >> Acee
> >>
> >> On 7/6/20, 1:14 PM, "Amanda Baber via RT" 
> >> 
> >> wrote:
> >>
> >> Hi Ketan, Peter,
> >>
> >> I believe we're waiting for Gunter to approve as the remaining 
> >> expert, but we can move ahead if Peter confirms that we don't need to wait.
> >>
> >> Best regards,
> >> Amanda
> >>
> >> On Mon Jul 06 03:46:02 2020, ket...@cisco.com wrote:
> >>> Hi Amanda/All,
> >>>
> >>> I thought that there was an agreement to assign bit 0x0010 for 
> >>> draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for draft-ietf-
> >>> lsr-
> >>> dynamic-flooding?
> >>>
> >>> Thanks,
> >>> Ketan
> >>>
> >>> -Original Message-
> >>>   From: Amanda Baber via RT 
> >>> Sent: 04 July 2020 07:53
> >>> To: Acee Lindem (acee) 
> >>> Cc: Peter Psenak (ppsenak) ; 
> >>> mraj...@juniper.net; lsr@ietf.org; Ketan Talaulikar (ketant) 
> >>> ; gunter.van_de_ve...@nokia.com; 
> >>> aretana.i...@gmail.com; alvaro.ret...@futurewei.com; 
> >>> acee=40cisco@dmarc.ietf.org
> >>> Subject: [IANA #1173602] Re: IANA early allocation request for 
> >>> draft- ietf-lsr-ospf-bfd-strict-mode
> >>>
> >>> Hi Peter, all,
> >>>
> >>>>> For both Peter and Gunter: the Flooding Request bit registration 
> >>>>> is described in the registry as a temporary allocation, but this 
> >>>>> may have been an mistake The RFC 7120 temporary early allocation 
> >>>>> procedure is meant for registries that require RFC publication 
> >>>>> for permanent registration. In theory, if the experts agree, 
> >>>>> permanent registrations can be made in Expert Review registries 
> >>>>> at any time.
> >>>>> Would there be an issue with removing the "TEMPORARY" 
> >>>>> designation from that registration?
> >>>>
> >>>> please go ahead and remove the TEMPORARY.
> >>>
> >>> The "TEMPORARY" designation has been removed from the 
> >>> draft-ietf-lsr- dynamic-flooding registration in LLS Type 1 
> >>> Extended Options and Flags, currently still assigned 0x0010:
> >>>
> >>> https://www.iana.org/assignments/ospf-lls-tlvs
> >>>
> >>> thanks,
> >>> Amanda
> >>
> >>
> > 
> > 
> > 
> 

___
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] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hi Aijun,

OSPF MIB RFC4750 was published before MADJ was introduced in OSPF. I would 
think it is quite natural that it does not consider MADJ. If your proposal is 
to fix/extend OSPF MIB in 202x for MADJ then do please go ahead.

As a reference you can look at how this is handled in the OSPF YANG model : 
https://tools.ietf.org/html/draft-ietf-ospf-yang-29#section-2.7

MADJ is a well-known, widely implemented and deployed feature. What we have 
been debating is more of a “point fix” to RFC5185.

So I do not follow what is it exactly that you are proposing?

Thanks,
Ketan

From: Aijun Wang 
Sent: 04 December 2020 12:31
To: Ketan Talaulikar (ketant) ; 'Acee Lindem (acee)' 
; 'Alexander Okonnikov' 
; 'Van De Velde, Gunter (Nokia - BE/Antwerp)' 

Cc: lsr@ietf.org; Peter Psenak (ppsenak) 
Subject: RE: [Lsr] Link Data value for Multi-area links

Hi, Ketan:

Using the local ip address or IfIndex can solve the correlation with the Link 
TLV in RFC3630, but it still does not resolve the ambiguity problem that 
required by RFC4750(OSPF MIB) as Acee mentioned.
Do we still follow this way?


Best Regards

Aijun Wang
China Telecom

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, December 3, 2020 5:35 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>; 
'Alexander Okonnikov' 
mailto:alexander.okonni...@gmail.com>>; 'Van De 
Velde, Gunter (Nokia - BE/Antwerp)' 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] Link Data value for Multi-area links

Hi Aijun,

Please check my previous response on this thread.

The matter is quite simple and easily addressed.

IMHO we do not need to invent a new protocol contraption or repurpose your 
stub-link proposal for this situation.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: 01 December 2020 09:22
To: 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>; 
'Alexander Okonnikov' 
mailto:alexander.okonni...@gmail.com>>; 'Van De 
Velde, Gunter (Nokia - BE/Antwerp)' 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi,

How about using the stub-link that we proposed and discussed at 
https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGFfhg/ to solve 
the scenario that described in RFC5185?
The possible solution is the following:
1)  The ABR form only the normal adjacency within the backbone area.
2)  For other area(for example, area 1) that they belong, each of them 
advertise the stub-link TLV, which include the network prefix that other 
area(area 1) belongs to, and also the metric to such prefix.
3)  The OSPF treat the prefixes within this stub-link TLV as the intra-area 
prefix in other area(area 1) and will prefer to using them over the inter-area 
prefix in the non-multi-area solution.
4)  More areas can be configured on such ABRs, eliminate the necessary to 
configure interface address within each area, also eliminate the ambiguity for 
using the remote peer address to differentiate the different adjacency.
5)  It is also easy to correlate such link information with the TE 
information that advertised in RFC3630.
Are the above proposal acceptable?

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: Tuesday, December 1, 2020 1:58 AM
To: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Speaking on WG member:

Hi Alex,
I knew this was coming. In 2008, 99.9% of the requirements were handled by 
supporting an interface in a primary area and one other area. Using the remote 
IP address for the other area does handle this case. As I stated previously, if 
you support OSPF adjacencies on secondary IP addresses, the MIB and other 
complexities are all taken care of and that would be the solution that I would 
recommend. However, if you guys want to spend time trying to improve RFC5185, 
you are perfectly welcome to submit a draft.

Thanks,
Acee

From: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 12:47 PM
To: Gunter Van de Velde 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak 
(ppsenak)" mailto:ppse...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Ketan Talaulikar (ketant)]

I support the WG adoption of this document. It covers an important piece of the 
FlexAlgorith solution space.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 02 December 2020 02:43
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hi Peter,

Please check inline below.

-Original Message-
From: Peter Psenak  
Sent: 03 December 2020 15:48
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; Van De Velde, Gunter (Nokia - BE/Antwerp) 
; Alexander Okonnikov 
; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Ketan,

On 03/12/2020 10:31, Ketan Talaulikar (ketant) wrote:
> Hello All,
> 
> The text in RFC5185 for picking the neighbor’s IP Address or IfIndex 
> for the link-data is indeed very odd and flies against how things are 
> done for normal p2p links per RFC2328.
> 
> The implementations that I am aware of do not really following this 
> “decision” of RFC5185 and instead stick to RFC2328 architecture by 
> picking the local IP address or IfIndex even for MADJ links. This way, 
> a remote router cannot really distinguish between a normal P2P link or 
> a MADJ – they look the same in the LSDB.
> 
> While the neighbor IP address can be learnt via the source address 
> used for the hello messages, there is really no simple way to learn 
> the neighbor’s IfIndex for unnumbered links [1].

rfc8510?
[KT] Yes

> 
> So IMHO the RFC5185 is in error and we should fix this if we have 
> consensus in the WG via a BIS as suggested by Acee.


I'm not convinced about the error. Nor about the need of the bis.
[KT] The question is why is RFC5185 not aligned with base OSPF RFC2328 on this 
aspect? What was the need for MADJ to have a reverse link-data information as 
compared to normal P2P links?

Thanks,
Ketan

my 2c,
Peter


> 
> Gunter, I am not getting into your other questions because of what 
> I’ve mentioned above 
> 
> Thanks,
> 
> Ketan
> 
> [1] Note that over time we have introduced such mechanisms (RFC8510), 
> but they have all been optional and not “base/required” behavior.
> 
> *From:*Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* 30 November 2020 23:18
> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
> ; Alexander Okonnikov 
> ; Peter Psenak (ppsenak) 
> ; Acee Lindem (acee) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Link Data value for Multi-area links
> 
> You are welcome to propose an alternate solution which could possibly 
> be accepted as a BIS document. However, this is not something that can 
> be simply changed in an Errata to reduce the complexity.
> 
> Thanks,
> Acee
> 
> *From: *Lsr mailto:lsr-boun...@ietf.org>> on 
> behalf of Gunter Van de Velde  <mailto:gunter.van_de_ve...@nokia.com>>
> *Date: *Monday, November 30, 2020 at 12:21 PM
> *To: *"Acee Lindem (acee)"  <mailto:acee=40cisco@dmarc.ietf.org>>, Alexander Okonnikov 
>  <mailto:alexander.okonni...@gmail.com>>,
> "Peter Psenak (ppsenak)"  <mailto:ppse...@cisco.com>>
> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>"  <mailto:lsr@ietf.org>>
> *Subject: *Re: [Lsr] Link Data value for Multi-area links
> 
> The oddnes is that the architecture decision in RFC5185 to select 
> remote-ip-address instead of local-ip-address for the ‘Link Data’ is 
> making things much more complicated.
> 
> I am surprised to see that using the remote-ip-address is seen as the 
> ‘better’ choice as selecting local-ip-address. To me it seems as a 
> worse choice.
> 
> A question that was asked: How router will be able to match Link TLV 
> (RFC 3630) to corresponding Link in Router LSA?
> 
> Answer:
> 
> For unnumbered links we can match Link TLV with Router TLV using the 
> IfIndex when there is no stub type 3 link (=easy)
> 
> For numbered:
> 
> 1.we must first look if the there is a stub type 3 link
> 
> 2.If stub type 3 exists, then the RFC3630 local ip address must be 
> used to identify the correspond link within the router TLV to the 
> neighbor
> 
> 3.If the stub type 3 link did not exist in Router TLV link, then the 
> maybe the link is unnumbered, and we try to match upon IfIndex… This 
> may give a match or no match
> 
> 4.If there is no match, then maybe the link is MADJ and we must use 
> the
> RFC3630 remote IP address to match upon the Link Data
> 
> 5.= over-complex. (If we used  for RFC5185 ‘Link Data = local ip 
> address’ then (2) would given answer directly)
> 
> In addition, for a router it is much simpler to learn and advertise 
> local-ip-address in Router LSAs then using a remote-ip-address.
> 
> I also believe that if we want to search something in TEDB after 
> receiving a TE Link TLV. How can we identify from the TE Link TLV if 
> multi-area or not multi-area? If we can not, then how can we create 
> the correct key?
> 
> Looking at the above, the choice of using remote-ip-address for 
> RFC5185 Link Data seems not the best design

Re: [Lsr] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hello All,

The text in RFC5185 for picking the neighbor’s IP Address or IfIndex for the 
link-data is indeed very odd and flies against how things are done for normal 
p2p links per RFC2328.

The implementations that I am aware of do not really following this “decision” 
of RFC5185 and instead stick to RFC2328 architecture by picking the local IP 
address or IfIndex even for MADJ links. This way, a remote router cannot really 
distinguish between a normal P2P link or a MADJ – they look the same in the 
LSDB.

While the neighbor IP address can be learnt via the source address used for the 
hello messages, there is really no simple way to learn the neighbor’s IfIndex 
for unnumbered links [1].

So IMHO the RFC5185 is in error and we should fix this if we have consensus in 
the WG via a BIS as suggested by Acee.

Gunter, I am not getting into your other questions because of what I’ve 
mentioned above 

Thanks,
Ketan

[1] Note that over time we have introduced such mechanisms (RFC8510), but they 
have all been optional and not “base/required” behavior.

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 30 November 2020 23:18
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Alexander Okonnikov ; Peter Psenak (ppsenak) 
; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

You are welcome to propose an alternate solution which could possibly be 
accepted as a BIS document. However, this is not something that can be simply 
changed in an Errata to reduce the complexity.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Gunter Van de Velde 
mailto:gunter.van_de_ve...@nokia.com>>
Date: Monday, November 30, 2020 at 12:21 PM
To: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, 
Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>, "Peter 
Psenak (ppsenak)" mailto:ppse...@cisco.com>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Link Data value for Multi-area links

The oddnes is that the architecture decision in RFC5185 to select 
remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
things much more complicated.
I am surprised to see that using the remote-ip-address is seen as the ‘better’ 
choice as selecting local-ip-address. To me it seems as a worse choice.

A question that was asked: How router will be able to match Link TLV (RFC 3630) 
to corresponding Link in Router LSA?

Answer:
For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
when there is no stub type 3 link (=easy)
For numbered:

1.  we must first look if the there is a stub type 3 link

2.  If stub type 3 exists, then the RFC3630 local ip address must be used 
to identify the correspond link within the router TLV to the neighbor

3.  If the stub type 3 link did not exist in Router TLV link, then the 
maybe the link is unnumbered, and we try to match upon IfIndex… This may give a 
match or no match

4.  If there is no match, then maybe the link is MADJ and we must use the 
RFC3630 remote IP address to match upon the Link Data

5.  = over-complex. (If we used  for RFC5185 ‘Link Data = local ip address’ 
then (2) would given answer directly)

In addition, for a router it is much simpler to learn and advertise 
local-ip-address in Router LSAs then using a remote-ip-address.
I also believe that if we want to search something in TEDB after receiving a TE 
Link TLV. How can we identify from the TE Link TLV if multi-area or not 
multi-area? If we can not, then how can we create the correct key?

Looking at the above, the choice of using remote-ip-address for RFC5185 Link 
Data seems not the best design that we can do, and is adding OSPF complexity 
without benefits.

Should this not be corrected in RFC5185 and simply use local-ip-address instead 
of the remote-ip-address for Multi-area Link Data and avoid the additional 
unnecessary complexity the current RFC for numbered links?

Brgds,
G/


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Monday, November 30, 2020 18:01
To: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Alex,

Multi-Area interface disambiguation is required to support the OSPF MIB as 
specified in RFC 4750. The table indexing doesn’t include the area. For example:

--  OSPF Interface Table

  ospfIfTable OBJECT-TYPE
   SYNTAX   SEQUENCE OF OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF Interface Table describes the interfaces
  from the viewpoint of OSPF.
  It augments the ipAddrTable with OSPF specific information."
   REFERENCE
  "OSPF Version 2, Appendix C.3  Router interface
  parameters"
   ::= { ospf 7 }

  ospfIfEntry OBJECT-TYPE
   SYNTAX  

Re: [Lsr] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hi Aijun,

Please check my previous response on this thread.

The matter is quite simple and easily addressed.

IMHO we do not need to invent a new protocol contraption or repurpose your 
stub-link proposal for this situation.

Thanks,
Ketan

From: Lsr  On Behalf Of Aijun Wang
Sent: 01 December 2020 09:22
To: 'Acee Lindem (acee)' ; 'Alexander 
Okonnikov' ; 'Van De Velde, Gunter (Nokia - 
BE/Antwerp)' 
Cc: lsr@ietf.org; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi,

How about using the stub-link that we proposed and discussed at 
https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGFfhg/ to solve 
the scenario that described in RFC5185?
The possible solution is the following:

  1.  The ABR form only the normal adjacency within the backbone area.
  2.  For other area(for example, area 1) that they belong, each of them 
advertise the stub-link TLV, which include the network prefix that other 
area(area 1) belongs to, and also the metric to such prefix.
  3.  The OSPF treat the prefixes within this stub-link TLV as the intra-area 
prefix in other area(area 1) and will prefer to using them over the inter-area 
prefix in the non-multi-area solution.
  4.  More areas can be configured on such ABRs, eliminate the necessary to 
configure interface address within each area, also eliminate the ambiguity for 
using the remote peer address to differentiate the different adjacency.
  5.  It is also easy to correlate such link information with the TE 
information that advertised in RFC3630.
Are the above proposal acceptable?

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Tuesday, December 1, 2020 1:58 AM
To: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Speaking on WG member:

Hi Alex,
I knew this was coming. In 2008, 99.9% of the requirements were handled by 
supporting an interface in a primary area and one other area. Using the remote 
IP address for the other area does handle this case. As I stated previously, if 
you support OSPF adjacencies on secondary IP addresses, the MIB and other 
complexities are all taken care of and that would be the solution that I would 
recommend. However, if you guys want to spend time trying to improve RFC5185, 
you are perfectly welcome to submit a draft.

Thanks,
Acee

From: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 12:47 PM
To: Gunter Van de Velde 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak 
(ppsenak)" mailto:ppse...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Acee,

RFC 5185 says that interface data structure is created for each multi-area 
adjacency. I guess that we are not allowed to allocate several ifIndex values 
for the same IP interface, because it is property of router's interface, not 
OSPF interface. Hence, we have several OSPF interfaces with the same ifIndex in 
unnumbered case and, thus, ambiguity in Interface table. The same for numbered 
- we have IP interface address (one), which is the same for multiple OSPF 
interfaces, and we again obtain ambiguity. Per my understanding advertising 
neighbor's IP address (or ifIndex) in Link Data doesn't help here.

30 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>> 
написал(а):

The oddnes is that the architecture decision in RFC5185 to select 
remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
things much more complicated.
I am surprised to see that using the remote-ip-address is seen as the ‘better’ 
choice as selecting local-ip-address. To me it seems as a worse choice.

A question that was asked: How router will be able to match Link TLV (RFC 3630) 
to corresponding Link in Router LSA?

Answer:
For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
when there is no stub type 3 link (=easy)
For numbered:

1.  we must first look if the there is a stub type 3 link

2.  If stub type 3 exists, then the RFC3630 local ip address must be used 
to identify the correspond link within the router TLV to the neighbor

3.  If the stub type 3 link did not exist in Router TLV link, then the 
maybe the link is unnumbered, and we try to match upon IfIndex… This may give a 
match or no match

4.  If there is no match, then maybe the link is MADJ and we must use the 
RFC3630 remote IP address to match upon the Link Data

5.  = over-complex. (If we used  for RFC5185 ‘Link Data = local ip address’ 
then (2) would given 

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

Thanks,
Ketan

From: Idr  On Behalf Of Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' ; 'Stephane Litkowski (slitkows)' 
; i...@ietf.org; 'Acee Lindem (acee)' 

Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:

I do believe the authors agreed to renaming the draft.

Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
the authors and interested IDR participants.

As the end of 12 days of the 14 day WG LC, this draft appears
to have general consensus from the WG as a useful draft.

I plan to allow 2 more days of comment, but at this point
it appears the WG wishes to adopt this draft.

Here’s my understanding of the best way forward:

If LSR adopts a version of the draft, IDR will allow the
LSR WG to be the main source as long as cross-working
review occurs so the BGP-only function can be reviewed.

Please continue to comment on the draft and
the planned progression.

Cheers,  Sue

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski (slitkows); 
i...@ietf.org; Acee Lindem (acee)
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

+1 to everything Acee said

Cheers,
Jeff
On Nov 10, 2020, 1:01 PM -0800, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>, 
wrote:
Speaking as an IDR WG member:

The name of the draft is wrong – the extension is for a Link MTU and not a path 
MTU.

Speaking as LSR Chair:

We could this in LSR as there is currently no MTU advertisement in the LSAs for 
OSPFv2 and OSPFv3. Implementations already make use of this information as it 
is used in the OSPF DBD packets and for LSA packing. Of course, we’d require a 
more accurate draft name and title.

Thanks,
Acee

From: Idr mailto:idr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Monday, November 9, 2020 at 4:20 PM
To: "'Stephane Litkowski (slitkows)'" 
mailto:slitkows=40cisco@dmarc.ietf.org>>,
 IDR List mailto:i...@ietf.org>>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Stephane:

My second message to this thread asked a few questions about the technology.

This information can be more than IGP information.   If SR segments statically 
defined (static or direct interfaces) tunnels and pass the endpoints via BGP 
tunnel-encaps draft with SR Policy tunnel type, this can just be BGP.

I’ll keep this WG adoption call going until we can be sure if:  1) it something 
LSR wants to standardize, and 2) whether there is a BGP only case.   It is 
clear to me that standardizing MTU for a SR segments with stacked tunnel 
segments passed by BGP was useful.

The authors should be the ones to 

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Zhibo,

I agree with everything that was discussed and concluded on that thread which 
you referred to.

It was about re-using existing sub-TLV for link MTU defined for Trill in ISIS. 
We are still saying the same thing! There is still the work required for the 
base ISIS procedures to be defined for the same.

Note that I did ask about the ISIS procedures for MTU during the last IETF 
online where the draft was presented. I was referred to the Trill spec at that 
time. But as we can clearly see those procedures are not applicable for normal 
ISIS.

Perhaps there was a misunderstanding somewhere in the middle that resulted in 
the approach that the authors took (i.e. assuming everything else was done and 
only BGP-LS remained) ?

In the thread the authors also spoke about OSPF but that seemed to have been 
dropped. As mentioned in my feedback, I am happy to help with if required.

Finally, I don’t see any opposition to the work itself or for it to be adopted 
(in due course). The discussion is on the “missing pieces” for this proposal to 
work and where this work is better accomplished.

Thanks,
Ketan

From: Huzhibo 
Sent: 14 November 2020 08:50
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (ketant) 
; Susan Hares ; 'Jeff Tantsura' 
; Stephane Litkowski (slitkows) ; 
i...@ietf.org; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft sh

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Sue,

I was referring to 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/

Seeing the interest in the WG to progress BGP-LS advertisements in BGP-only 
networks, I would request for the WG to consider adoption of the above draft. I 
believe the problem statement of the draft is clear and acknowledge that it 
needs updates. So I will leave it to the chairs’ judgement if it is in a good 
enough state for adoption 

Thanks,
Ketan

From: Susan Hares 
Sent: 16 November 2020 11:40
To: 'Jeff Tantsura' ; Les Ginsberg (ginsberg) 

Cc: Ketan Talaulikar (ketant) ; Stephane Litkowski (slitkows) 
; i...@ietf.org; Acee Lindem (acee) ; 
lsr@ietf.org
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff:

I agree your BGP-LS only deployment in the MSD document were not well defined.

Starting a new set of work to define BGP-LS use in BGP-only is important.  If 
this document start the process to refine how BGP-only works, this will help 
defined this usage.   I stand by the agreement that the BGP-LS that exposes the 
OSPF/ISIS Link MTU proposal can be adopted in LSR.  However, this discussion 
has confirmed that the BGP-LS support for BGP-only needs some BGP focus.

If there are other drafts on this topic, it would be good to suggest this 
drafts on the list.   Ketan suggested he had one.

Cheers, Sue


From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Friday, November 13, 2020 8:52 PM
To: Les Ginsberg (ginsberg)
Cc: Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski (slitkows); 
i...@ietf.org<mailto:i...@ietf.org>; Acee Lindem (acee); 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

To add to Les’s point of BGP only scenario, during MSD IESG reviews, BGP-LS 
only deployment was found not well characterized and had been removed from the 
draft. It will require much better discussion to have it included.
Regards,
Jeff

On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4<https://tools.

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

Hi Chris,

Thanks for the update and we've just posted 
https://tools.ietf.org/html/draft-ietf-lsr-ospf-l2bundles-00

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 29 October 2020 23:57
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; 
draft-ketant-lsr-ospf-l2bundles@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

The document is adopted.

Authors, please resubmit as draft-ietf-lsr-ospf-l2bundles-00

Thanks,
Chris.

> On Oct 2, 2020, at 8:03 AM, Christian Hopps  wrote:
> 
> Signed PGP part
> This begins a 2 week WG adoption call for the following draft:
> 
>  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/
> 
> Please indicate your support or objection by October 16, 2020.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
> 
> Thanks,
> Chris and Acee.
> 
> 

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

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

Hi Acee/All,

I am not aware of any undisclosed IPR related to this draft.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 16 June 2021 19:31
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Ketan Talaulikar (ketant)]

One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of peng.sha...@zte.com.cn
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com
Cc: lsr@ietf.org; cho...@chopps.org
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed. 


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and Chris.

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

--

Gyan Mishra
Network Solutions Architect
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] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Ketan Talaulikar (ketant)]

Hi Gyan,

This document does not even “update” the LSR Flex-Algo draft since it is 
introducing something new and on top. It does not change what’s in the LSR 
Flex-Algo draft.

This document would be pretty much independent and an optional/add-on element 
on top of the LSR Flex-Algo solution.

Thanks,
Ketan

From: Gyan Mishra 
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) 
Cc: cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Gyan>This is a confusing point and maybe something the authors can clarify 
in the text.  So this  draft defines a new Adj-Sid that has an Algo identifier 
specifically for Flex Algo and if that’s the case I agree it does not update 
the SR-MPLS IGP extensions, but instead should update the Flex Algo extensions.


Thanks,
Ketan

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org<mailto:lsr@ietf.org>;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed.


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and Chris.

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

--

Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>
M 301 502-1347
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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