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

[Jeff Tantsura]

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 on Sec 4:
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 interpret them? 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 5

 
Suggest to add “When a Link MSD type is not signalled but the Node MSD type is, 
then the value of that Link MSD type MUST considered as the corresponding Node 
MSD type value.” I realize this is obvious but it is better to be clarified. 
This enables routes with homogenous link MSD values to advertise just the Node 
MSD values. I also think this should be RECOMMENDED by the draft for flooding 
efficiencies.
 
Sec 6
 
   The Base MPLS Imposition MSD (BMI-MSD) signals the total number of
   

Re: [Lsr] RtgDir Early review: draft-ietf-ospf-segment-routing-msd.txt

[Jeff Tantsura]

Hi Tal,

 

New version (11) should address all your comments.

Many thanks and please let me know, if there’s anything else.

 

Cheers,

Jeff

From: Tal Mizrahi 
Date: Sunday, April 29, 2018 at 04:08
To: , , 

Cc: , 
Subject: Re: RtgDir Early review: draft-ietf-ospf-segment-routing-msd.txt
Resent-From: 
Resent-To: Jeff Tantsura , , 
, 
Resent-Date: Sun, 29 Apr 2018 04:08:12 -0700 (PDT)

 

+ LSR mailing list.

 

Cheers,

Tal.

 

On Sun, Apr 29, 2018 at 2:04 PM, Tal Mizrahi  wrote:

Hello

I have been selected to do a routing directorate “early” review of this draft. 
​https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/

The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG. The early review can be performed at any time during the draft’s lifetime 
as a working group document. 

For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-ospf-segment-routing-msd.txt 
Reviewer: Tal Mizrahi
Review Date: April 2018 
Intended Status: Standards Track

Summary: 
This document is basically ready for publication, but has a couple of issues 
and a few nits that should be considered prior to being submitted to the IESG.

Comments:
The Security Considerations should be more detailed. The reference to RFC 7770 
is a good start, but please add more details about potential attacks. For 
example, what happens if there is a spoofed MSD with a low MSD value? What is 
the impact of such an attack?
Section 3:
The description of the Length field says “minimum of 2”, implying it can be 
higher than 2.
On the other hand, the Value field: “consists of a 1 octet sub-type (IANA 
Registry) and 1 octet value.”, which implies that the Length is equal to 2.
Please align the two descriptions, i.e., if flexibility for future sub-types is 
required, please change the description of Value to allow longer values..
The comment applies to Section 4 as well.
Nits:
The term “minimum MSD”, which translates to “minimum maximum SID Depth” should 
be explained.
The term “maximum MSD” appears twice in the document, which seems either 
redundant, or a typo (did you mean minimum MSD?).
The acronym SID should be spelled out on its first use.
The acronyms RI and LSA should be added to the Terminology subsection.
Section 1.1.1 and Section 2 are both titled “Terminology”. It would be best to 
merge Section 1.1 into Section 2, and avoid the duplicate title.
“each node/link a given SR path” -> “each node/link of a given SR path”
“nodes and links which has been configured” -> “nodes and links that have been 
configured”
“laso”->”also”
“Other Sub-types other than defined” -> “Sub-types other than defined”
 

 

Cheers,

Tal Mizrahi.

 

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