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

2018-05-10 Thread 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"

2018-05-11 Thread 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

2018-05-23 Thread 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

2018-06-18 Thread 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)

2018-06-13 Thread 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

2018-06-05 Thread 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

2018-06-05 Thread 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

2018-06-18 Thread 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

2018-07-17 Thread 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

2018-07-17 Thread 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

2018-07-17 Thread 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

2018-07-24 Thread 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

2018-07-17 Thread 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

2018-07-05 Thread 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

2018-04-07 Thread 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

2018-04-10 Thread 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

2018-04-12 Thread 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

2018-04-09 Thread 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] LSR Working Group Adoption Poll for Flex Algorithm Drafts

2018-04-17 Thread Ketan Talaulikar (ketant)
Support as co-author and also support combining the OSPF and ISIS aspects in a 
single draft.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 17 April 2018 20:14
To: lsr@ietf.org
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

This begins a two-week adoption poll for the following Flex Algorithm drafts:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

The adoption poll will end at 12:00 AM EST on May 2nd, 2018. Please indicate 
your support of opposition of the drafts.

Additionally, the authors are amenable to combining the drafts into a single 
draft. If you have an opinion, please state that as well.

Thanks,
Acee




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


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

2018-04-23 Thread 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

2018-04-23 Thread 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

2018-04-02 Thread 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

2018-04-04 Thread 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

2018-10-24 Thread 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

2018-10-28 Thread 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

2019-02-22 Thread 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.

2019-02-22 Thread 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

2019-03-11 Thread 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

2019-03-06 Thread 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

2019-02-13 Thread 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)

2019-04-10 Thread 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

2019-04-11 Thread 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

2019-05-15 Thread 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

2019-05-09 Thread 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

2019-05-10 Thread 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

2019-07-08 Thread 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

2019-07-26 Thread 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

2019-07-25 Thread 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

2019-07-25 Thread 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

2019-07-26 Thread 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

2019-07-08 Thread 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

2019-11-17 Thread 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

2019-11-17 Thread 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

2019-12-13 Thread 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

2019-12-13 Thread 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

2019-12-05 Thread 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

2020-03-03 Thread 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

2020-02-27 Thread 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

2020-02-28 Thread 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

2020-01-23 Thread 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

2020-01-29 Thread 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

2020-01-30 Thread 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

2020-01-31 Thread 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

2020-01-31 Thread 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

2020-01-24 Thread 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

2020-01-30 Thread 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

2020-02-12 Thread 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

2020-01-15 Thread 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

2020-01-06 Thread 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

2020-01-07 Thread 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

2020-01-07 Thread 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

2020-03-12 Thread 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

2020-03-12 Thread 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

2020-03-12 Thread 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

2020-05-09 Thread 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] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt

2020-06-30 Thread 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

2020-06-30 Thread 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

2020-06-30 Thread 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

2020-06-30 Thread 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

2020-07-05 Thread 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

2020-07-02 Thread 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

2020-07-08 Thread 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] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-17 Thread 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

2020-08-18 Thread 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

2020-08-18 Thread 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

2020-08-18 Thread 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

2020-08-17 Thread 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

2020-08-14 Thread 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

2020-08-14 Thread 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

2020-08-19 Thread 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

2020-09-24 Thread 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