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

["Ketan Talaulikar (ketant)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Christian Hopps
Sent: 23 April 2018 19:33
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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&url2=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
[e-mail]
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<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 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
   MPLS labels a node is capable of imposing, including any all service/
   Transport/special labels.

Sec 8

I think the security section just points to the RI LSA draft, but it also needs to cover the other LSAs. IMHO the security considerations are fairly generic for the protocols but we need the right references here?

Thanks,
Ketan



From: Lsr <[e-mail]> On Behalf Of Acee Lindem (acee)
Sent: 06 April 2018 06:19
To: [e-mail]
Subject: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.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, April 20th, 2018.



Thanks,

Acee and Chris

--- End Message ---