Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt

2018-05-10 Thread Les Ginsberg (ginsberg) 
This is a minor editorial revision to make the draft consistent w 
draft-ietf-ospf-segment-routing-msd-12.

   Les

> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Thursday, May 10, 2018 5:49 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.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   : Signaling MSD (Maximum SID Depth) using IS-IS
> Authors : Jeff Tantsura
>   Uma Chunduri
>   Sam Aldrin
>   Les Ginsberg
>   Filename: draft-ietf-isis-segment-routing-msd-11.txt
>   Pages   : 9
>   Date: 2018-05-10
> 
> Abstract:
>This document defines a way for an IS-IS Router to advertise multiple
>types of supported Maximum SID Depths (MSDs) at node and/or link
>granularity.  Such advertisements allow entities (e.g., centralized
>controllers) to determine whether a particular SID stack can be
>supported in a given network.  This document only defines one type of
>MSD maximum label imposition, but defines an encoding that can
>support other MSD types.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-11
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd-
> 11
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd-11
> 
> 
> 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] Working Group Last Call on "Signaling MSD (Maximum SID Depth) using OSPF"

2018-05-10 Thread Acee Lindem (acee) 
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] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

2018-05-10 Thread Jeff Tantsura 
Hi Ketan,

 

Many thanks for you thoughtful reviews, working with the authors to improve the 
draft! 

 

Cheers,

Jeff

From: "Ketan Talaulikar (ketant)" 
Date: Thursday, May 10, 2018 at 08:05
To: Jeff Tantsura , "Acee Lindem (acee)" 
, "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 Jeff,

 

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

 

Thanks,

Ketan

 

From: Jeff Tantsura  
Sent: 08 May 2018 04:53
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; 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  on behalf of "Ketan Talaulikar (ketant)" 

Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" , "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 J

 

General Qs:
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.
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.
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.
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.
Several comments below about the section where OSPF TLVs are defined and I 
would suggest to use similar text as in the ISIS draft.
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.
Reference to RFC4970 should be replaced with RFC7770
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:
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.
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

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 
Sent: 08 May 2018 04:53
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; 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 > on behalf of 
"Ketan Talaulikar (ketant)" >
Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" >, 
"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],
 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 Attribute/E-Router LSA and when there are multiple instances 
then how should the receiver handle or