Signaling Maximum SID Depth (MSD) Using OSPF
draft-ietf-ospf-segment-routing-msd-25

[Ballot comment]
Thanks for addressing my Discuss point; original ballot comment preserved below.

Can SID be expanded on first usage --
https://www.rfc-editor.org/materials/abbrev.expansion.txt does not list it
as "well known".  (It also doesn't appear to list "Segment Identifier" as
one of the expansions.)

This is basically the same thing I said for the IS-IS document that creates
the MSD types registry, but I'm not sure I followed correctly the meaning
of MSD type 1 for SR-enabled vs.  non-SR-enabled networks.  In particular,
I still don't really understand why it's okay to use the same codepoint for
the max SID depth in SR-enabled networks and for the max label depth in
non-SR MPLS networks.  Why couldn't they just be separate MSD Type
codepoints?

Section-by-section comments follow.

Section 2

                  If the Node MSD TLV appears in multiple Router
  Information LSAs that have the same flooding scope, the Node MSD TLV
  in the Router Information (RI) LSA with the numerically smallest
  Instance ID MUST be used and subsequent instances of the Node MSD TLV
  MUST be ignored. [...]

Unless there is a sorting requirement I've forgotten about, shouldn't this
be "other" rather than "subsequent"?

Section 6

Thanks for the updates in response to the secdir review; they help a lot.

  If the value is larger than supported - instantiation of a path that
  can't be supported by the head-end (the node performing the SID
  imposition).

This is supposed to mean "(instantiation by the head-end) of a (path that
can't be supported)", not "instantiation of a path (that can't be supported
by the head-end)", right?

[Ballot discuss]
This is essentially a process discuss, and hopefully easy to resolve.

In Section 4, we say:

  The meaning of the absence of both Node and Link MSD advertisements
  for a given MSD type is specific to the MSD type.  Generally it can
  only be inferred that the advertising node does not support
  advertisement of that MSD type.  However, in some cases the lack of
  advertisement might imply that the functionality associated with the
  MSD type is not supported.  The correct interpretation MUST be
  specified when an MSD type is defined.

I don't think we can make this sort of normative requirement on a registry
created by a different document, at least not without updating the registry
to also point to this document.

[Ballot comment]
Can SID be expanded on first usage --
https://www.rfc-editor.org/materials/abbrev.expansion.txt does not list it
as "well known".  (It also doesn't appear to list "Segment Identifier" as
one of the expansions.)

This is basically the same thing I said for the IS-IS document that creates
the MSD types registry, but I'm not sure I followed correctly the meaning
of MSD type 1 for SR-enabled vs.  non-SR-enabled networks.  In particular,
I still don't really understand why it's okay to use the same codepoint for
the max SID depth in SR-enabled networks and for the max label depth in
non-SR MPLS networks.  Why couldn't they just be separate MSD Type
codepoints?

Section-by-section comments follow.

Section 2

                  If the Node MSD TLV appears in multiple Router
  Information LSAs that have the same flooding scope, the Node MSD TLV
  in the Router Information (RI) LSA with the numerically smallest
  Instance ID MUST be used and subsequent instances of the Node MSD TLV
  MUST be ignored. [...]

Unless there is a sorting requirement I've forgotten about, shouldn't this
be "other" rather than "subsequent"?

Section 6

Thanks for the updates in response to the secdir review; they help a lot.

  If the value is larger than supported - instantiation of a path that
  can't be supported by the head-end (the node performing the SID
  imposition).

This is supposed to mean "(instantiation by the head-end) of a (path that
can't be supported)", not "instantiation of a path (that can't be supported
by the head-end)", right?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ospf-segment-routing-msd-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the OSPF Router Information (RI) TLVs registry on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters/

the existing, early registration:

Value: 12
TLV Name: Node MSD TLV
Reference: [current draft]

will be made permanent and have its reference changed to [ RFC-to-be ].

Second, in the OSPFv2 Extended Link TLV Sub-TLVs registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

https://www.iana.org/assignments/ospfv2-parameters/

the existing, early registration:

Value: 6
Description: Link MSD sub-TLV
Reference: [current draft]

will be made permanent and have its reference changed to [ RFC-to-be ].

Third, in the OSPFv3 Extended-LSA TLVs registry on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

https://www.iana.org/assignments/ospfv3-parameters/

a single, new value will be registered as follows:

Value: [ TBD-at-Registration ]
Description: [.see question below]
Reference: [ RFC-to-be ]

IANA Question --> in the IANA Considerations section of this document, the authors request: "Finally, this document requests IANA to allocate a sub-TLV type (TBD3) from the OSPFv3 Extended-LSA Sub-TLV registry." What should the description be for this new sub-TLV type?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-08-29):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ospf-segment-routing-msd@ietf.org, aretana.ietf@gmail.com, lsr-chairs@ietf.org, Acee Lindem , lsr@ietf.org, acee@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Signaling MSD (Maximum SID Depth) using OSPF) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Signaling MSD (Maximum SID Depth) using
OSPF'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a way for an OSPF 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 defines only one type of
  MSD, but defines an encoding that can support other MSD types.  Here
  the term OSPF means both OSPFv2 and OSPFv3.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3040/
  https://datatracker.ietf.org/ipr/3254/

=== AD Review of draft-ietf-ospf-segment-routing-msd-15 ===
(https://mailarchive.ietf.org/arch/msg/lsr/UxlrEElZlLgGqWjOAg8ILGsiJt8)

Dear authors:

I just finished reading this document.  I have several comments and concerns that I included inline below.

While I do have some significant concerns (see below), I don't think there are specific items that prevent the start of the IETF LC (they should not be hard to address), so I'm getting that underway.  However, given the close relationship to and dependency on draft-ietf-isis-segment-routing-msd, I will schedule both of them on the same IESG Telechat.

Thanks!

Alvaro.


...
76 1.  Introduction

78  When Segment Routing(SR) paths are computed by a centralized
79  controller, it is critical that the controller learns the Maximum SID
80  Depth(MSD) that can be imposed at each node/link on a given SR path
81  to insure that the SID stack depth of a computed path doesn't exceed
82  the number of SIDs the node is capable of imposing.

[nit] s/Depth(MSD)/Depth (MSD)

84  The PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals
85  MSD in SR PCE Capability TLV and METRIC Object.  However, if PCEP is
86  not supported/configured on the head-end of an SR tunnel or a
87  Binding-SID anchor node and controller do not participate in IGP

[nit] s/and controller do not participate/and the controller does not participate

88  routing, it has no way to learn the MSD of nodes and links.  BGP-LS
89  [RFC7752] defines a way to expose topology and associated attributes
90  and capabilities of the nodes in that topology to a centralized
91  controller.  MSD signaling by BGP-LS has been defined in
92  [I-D.ietf-idr-bgp-ls-segment-routing-msd].  Typically, BGP-LS is
93  configured on a small number of nodes that do not necessarily act as
94  head-ends.  In order for BGP-LS to signal MSD for all the nodes and
95  links in the network MSD is relevant, MSD capabilites should be
96  advertised by every OSPF router in the network.

[nit] s/capabilites/capabilities

...
108  or SIDs associated with another dataplane e.g., IPv6.  Although MSD
109  advertisements are associated with Segment Routing, the
110  advertisements MAY be present even if Segment Routing itself is not
111  enabled.

[minor] Given that you're using Normative language...  It would be nice if you expanded on the use of the MSD in a non-SR network.  Something simple such as "a SID and a label are the same thing" would be enough.

113 1.1.  Conventions used in this document

115 1.1.1.  Terminology

[minor] Except for BMI/MSD, the other terms are not definitions, just expansions.  Some of the abbreviations are already included in the RFC Editor Abbreviations List [1].  In general, it would be better to just expand on first use (BGP-LS, for example) is used *before* this section than to have this section with expansions.

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

...
152 2.  Node MSD Advertisement

154  The node MSD TLV within the body of the OSPF RI Opaque LSA is defined

[nit] A reference to rfc7770 would be nice.

155  to carry the provisioned SID depth of the router originating the RI
156  LSA.  Node MSD is the smallest MSD supported by the node on the set
157  of interfaces configured for use by the advertising IGP instance.
158  MSD values may be learned via a hardware API or may be provisioned..

160        0                  1                  2                  3
161        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

163      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
164      |    Type                      |        Length                |
165      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
166      |        MSD Type and Value ...
167      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

169                          Figure 1: Node MSD TLV

[nit] It would be nicer to display the actual pairs:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  MSD-Type    | MSD-Value    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


171  The Type: TBD1

173  Length: variable (minimum of 2, multiple of 2 octets) and represents
174  the total length of value field.

[nit] ...in octets.

176  Value: consists of one or more pairs of a 1 octet MSD-type and 1
177  octet MSD-Value.

[nit] There is no "Value" field illustrated above.  You might want to reword a little.

...
188  This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is
189  optional.  The scope of the advertisement is specific to the
190  deployment.

[minor] I'm confused by the reference to rfc5838.  It confuses me because there are no references to the base specs (rfc2328/rfc5340), but (when it seems that one is maybe used) you point at rfc5838 here...

192  When multiple Node MSD TLVs are received from a given router, the
193  receiver MUST use the first occurrence of the TLV in the Router
194  Information LSA.  If the Node MSD TLV appears in multiple Router
195  Information LSAs that have different flooding scopes, the Node MSD
196  TLV in the Router Information LSA with the area-scoped flooding scope
197  MUST be used.  If the Node MSD TLV appears in multiple Router
198  Information LSAs that have the same flooding scope, the Node MSD TLV
199  in the Router Information (RI) LSA with the numerically smallest
200  Instance ID MUST be used and subsequent instances of the Node MSD TLV
201  MUST be ignored.  The RI LSA can be advertised at any of the defined
202  opaque flooding scopes (link, area, or Autonomous System (AS)).  For
203  the purpose of Node MSD TLV advertisement, area-scoped flooding is
204  REQUIRED.

[major] The text above ends by saying that for the "Node MSD TLV advertisement, area-scoped flooding is REQUIRED".  I take that to mean that other scopes are not valid, is that true?

If so, then the rules seem to contradict themselves; specifically: "If the Node MSD TLV appears in multiple Router Information LSAs that have the same flooding scope..." seems to imply that receiving the Node MSD TLV in an non-area scoped RI LSAs is ok.

206 3.  Link MSD sub-TLV
...
223  Type:

225  For OSPFv2, the Link level MSD value is advertised as an optional
226  Sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684], and
227  has value of TBD2.

229  For OSPFv3, the Link level MSD value is advertised as an optional
230  Sub-TLV of the E-Router-LSA TLV as defined in [RFC8362], and has
231  value of TBD3.

[nit] For both OSPFv2/OSPFv3, it would be clearer if "has a type of TBD" (instead of "value") was used.  The "value" is used to mean different things in the same sentence.

233  Length: variable and similar to that, defined in Section 2.

[major] Similar or the same?

235  Value: consists of one or more pairs of a 1 octet MSD-type and 1
236  octet MSD-Value.

[nit] There is no "Value" field illustrated above.  You might want to reword a little.

...
248  Other MSD Types are reserved for future extensions.

[major] The MSD Types are not defined in this document...so they shouldn't be reserved here...

250  If this TLV is advertised multiple times in the same OSPFv2 Extended
251  Link Opaque LSA, only the first instance of the TLV is used by
252  receiving OSPFv2 routers.  This situation SHOULD be logged as an
253  error.

[nit] s/this TLV/this sub-TLV

[major] Can we make the specification stronger?  Maybe "only the first instance MUST be used"...

255  If this TLV is advertised multiple times for the same link in
256  different OSPFv2 Extended Link Opaque LSAs originated by the same
257  OSPFv2 router, the OSPFv2 Extended Link TLV in the OSPFv2 Extended
258  Link Opaque LSA with the smallest Opaque ID is used by receiving
259  OSPFv2 routers.  This situation may be logged as a warning.

[nit] s/this TLV/this sub-TLV

[major] Can we make the specification stronger?  Maybe "...with the smallest Opaque ID MUST be used...".

[minor] Why is the importance of this last situation less, where a warning may (non-normative) be logged?

[major] What about multiples in OSPFv3?

261 4.  Using Node and Link MSD Advertisements

[major] After reading this section, I still don't know how do use the advertisements.  What should a receiver do with the values?  Maybe the use is constrained to a controller...maybe the exact operation is our of the scope of this document.  Either way, please say something.

...
279 5.  Base MPLS Imposition MSD

[minor] Even with the pointer to I-D.ietf-isis-segment-routing-msd, this section is not needed in this document because the definition of the MSD-Types is done elsewhere.  Please remove it.

...
301 7.  Security Considerations

303  Security concerns for OSPF are addressed in [RFC7474].  Further

[minor] That's a bold statement!  I'm sure those are not the only security concerns...  It may be better to just point at the base specifications...

304  security analysis for OSPF protocol is done in [RFC6863] including
305  analysis of both the above documents.  Security considerations, as

[minor] Which documents?

306  specified by [RFC7770], [RFC7684] and [RFC8362] are applicable to
307  this document.

309  Advertisement of an incorrect MSD value may result: in a path
310  computation failing and the service unavailable or instantiation of a
311  path that can't be supported by the head-end (the node performing the
312  imposition).

[major] The paragraph above can also applied to modified information.  What about privacy?  What are the issues with disclosure of the MSDs?

...
329 10.1.  Normative References

[minor] I don't think that rfc7474 needs to be Normative.

...
342  [RFC7474]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
343              "Security Extension for OSPFv2 When Using Manual Key
344              Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
345              .

...
366 10.2.  Informative References

[nit] rfc8126 is not used.

...
403  [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
404              Writing an IANA Considerations Section in RFCs", BCP 26,
405              RFC 8126, DOI 10.17487/RFC8126, June 2017,
406              .

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to OSPFv2/OSPFv3 Router
      Information (RI) TLV to specify the MPLS Maximum Segment Depth (MSD)
      for an OSPFv2/OSPFv3 router. Additionally, extensions are specified
      in OSPFv2 Prefix/Link attributes LSA and the OSPFv3 Extended-Router-LSA
      to advertise the MSD for an OSPFv2/OSPFv3 link. The specification
      supports multiple types of MSD, as well as, an IANA registry for
      the types. The initial and only type specified is the Label
      Imposition MSD, i.e., the maximum number of labels that can be
      imposed for a link or router (minimum of all links).

Working Group Summary:
   
      Once the precise defintion of MSD was agreed upon at the Chicago
      IETF, the draft has been relatively stable and the changes have
      been mainly procedural (i.e., the designation of a common MSD
      type IANA registry) or editorial (e.g., handling multiple
      MSD TLVs).

Document Quality:

      This document has been a WG document for 1 1/2 years and has had
      several good reviews. The authors have been very responsive to
      comments and I believe the document is ready for publication.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list. Additionally,
    the document shepherd provided editorial updates for consistency
    with other OSPF RFCs. The document shepherd fully believes that the
    document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

      Yes.

      https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ospf-segment-routing-msd

      No concerns have been voiced. IPR declaration is common for LSR
      drafts.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No. Publication for "IS-IS MSD" will be requested concurrently.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

    The IANA considerations section is clear and early allocatios have
    been made for the requeted code points.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

    Not applicable. The new MSD Type registry is covered by the IS-IS
    MSD draft.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.