Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane
draft-ietf-mpls-rsvp-shared-labels-09

[Ballot comment]
[Leaving my position as "No Record" since I didn't finish my review before the telechat.
Hopefully the comments can still be useful.]

Section 2

I agree with the Gen-ART reviewer that defining "loose hop" would be
helpful.

  Delegation label:  A label assigned at the delegation hop to
      represent a set of labels that will be pushed at this hop.

A terminology question (or perhaps just my ignorance), but is "assigned at"
the proper wording for this?  My initial reading was that this label would
be added to the stack while traversing ("at") the delegation hop, but that
doesn't really make sense given the rest of the definition.

Section 5.1.2

  The downside of this approach is that the number of hops that the LSP
  can traverse is dictated by the label stack push limit of the
  ingress.

There is perhaps some more subtlety here, in that the interaction involves
both the label stack push limit at the ingress, but also the number of
delegation labels and TE link labels not included in a delegation.  Thus,
the difference between this case and the "stack to reach delegation hop"
method is that all delegation hops after the first one will decrease the
effective label stack push limit at the ingress (for the path to the first
delegation hop).  It's not clear that this paragraph does a good job of
summarizing that distinction, as-is.

Section 5.3.1

It's unclear to me whether, after such a gap in ETLD support, the next
node that supports ETLD is supposed to decrement the ETLD value by just one
or by the total number of nodes (accounting for itself and the
non-ETLD-supporting nodes), assuming that the ETLD remains positive after
such an operation.

Section 9.1

  o  When the use of TE link labels is mandated/requested for the path:
[...]
      *  When explicit delegation is mandated or automatic delegation is
        requested:

        +  the ingress SHOULD have the ability to indicate the chosen
            stacking approach (and)

        +  the delegation hop SHOULD have the ability to indicate that
            the recorded label is a delegation label.

Does the first one need to be a MUST?  The behavior of the delegation hop
depends on the chosen stacking approach, and I can't quite convince myself
that it would always be determinable just from inspecting the stack on
ingress to the delegation hop.

Section 9.4

nit: the wording "MUST be set [...] only if" is a bit awkward; what we
really want to say is that if TE link labels are not in use/recording for
this LSP, then this flag MUST NOT be set ... right?

[Ballot comment]
Section 2

I agree with the Gen-ART reviewer that defining "loose hop" would be
helpful.

  Delegation label:  A label assigned at the delegation hop to
      represent a set of labels that will be pushed at this hop.

A terminology question (or perhaps just my ignorance), but is "assigned at"
the proper wording for this?  My initial reading was that this label would
be added to the stack while traversing ("at") the delegation hop, but that
doesn't really make sense given the rest of the definition.

Section 5.1.2

  The downside of this approach is that the number of hops that the LSP
  can traverse is dictated by the label stack push limit of the
  ingress.

There is perhaps some more subtlety here, in that the interaction involves
both the label stack push limit at the ingress, but also the number of
delegation labels and TE link labels not included in a delegation.  Thus,
the difference between this case and the "stack to reach delegation hop"
method is that all delegation hops after the first one will decrease the
effective label stack push limit at the ingress (for the path to the first
delegation hop).  It's not clear that this paragraph does a good job of
summarizing that distinction, as-is.

Section 5.3.1

It's unclear to me whether, after such a gap in ETLD support, the next
node that supports ETLD is supposed to decrement the ETLD value by just one
or by the total number of nodes (accounting for itself and the
non-ETLD-supporting nodes), assuming that the ETLD remains positive after
such an operation.

[Ballot comment]
I support Alvaro's DISCUSS -- it seems that this should be addressed / better discussed.

I'm balloting NoObj (trusting sponsoring AD) - I would would have liked to have been able to do a more thorough review, but simply ran out of time (and what I did manage to review left me feeling happy that it is good).

[Ballot comment]
Thanks to everyone who worked on this document. I have a handful
of comments.

---------------------------------------------------------------------------

§7:

>  The following logic could be used by the node constructing the label
>  stack:
>
>    Each RRO label sub-object SHOULD be processed starting with the
>    label sub-object from the first downstream hop.  Any label
>    provided by the first downstream hop MUST always be pushed on the
>    label stack regardless of the label type.  If the label type is a
>    TE link label, then any label from the next downstream hop MUST
>    also be pushed on the constructed label stack.  If the label type
>    is a regular label, then any label from the next downstream hop
>    MUST NOT be pushed on the constructed label stack.  If the label
>    type is a delegation label, then the type of stacking approach
>    chosen by the ingress for this LSP (Section 5.1) MUST be used to
>    determine how the delegation labels are pushed in the label stack.

The use of normative language in example text is very confusing. I fear that
this processing will be read as normative rather than the example that it
appears to be ("could be used"). I believe what you want is something more
like:

      Each RRO label sub-object will be processed starting with the
      label sub-object from the first downstream hop.  Any label
      provided by the first downstream hop will always be pushed on the
      label stack regardless of the label type.  If the label type is a
      TE link label, then any label from the next downstream hop will
      also be pushed on the constructed label stack.  If the label type
      is a regular label, then any label from the next downstream hop
      will not be pushed on the constructed label stack.  If the label
      type is a delegation label, then the type of stacking approach
      chosen by the ingress for this LSP (Section 5.1) will be used to
      determine how the delegation labels are pushed in the label stack.

Alternately, if the text is meant to be normative, then the introductory
sentence needs to be changed ("is used" or "must be used"), and the paragraph
itself should probably not be indented.

---------------------------------------------------------------------------

§8.1:

>  To provide link protection at a Point of Local Repair (PLR) with a
>  shared MPLS forwarding plane, the LSR SHOULD allocate a separate TE
>  link label for the TE link that will be used for RSVP-TE tunnels that
>  request link protection from the ingress.

This isn't really my area, but from the fuzzy model I have in my head about link
protection, it seems to me that this won't actually work unless a new label is
allocated -- right? If that's the case, then the preceding "SHOULD" would appear
to actually be a "MUST".

Or is the notion that some LSR might choose to simply treat all traffic as
link-protected?

---------------------------------------------------------------------------

§9.2:

>  When a node that does not cater to the mandate
>  receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object
>  with this flag set, it MUST send a PathErr message with an error code
>  of 'Routing Problem (24)' and an error value of 'TE link label usage
>  failure (TBD3)'.

I'm a little confused about how this is intended to work. At first, this looked
like it might just be a restatement of the behavior of LSP_REQUIRED_ATTRIBUTES;
however, it's unclear how existing, already deployed nodes are going to be able
to send an error value of TBD3.

This same comment applies to §9.4.

[Ballot discuss]
A significant portion of this specification depends on knowing the label stack depth limits in the network, but §5.2 declares the mechanism out of scope:

  In order to accurately pick
  the delegation hops, the ingress needs to be aware of the label stack
  depth push limit of each of the transit LSRs prior to initiating the
  signaling sequence.  The mechanism by which the ingress or controller
  (hosting the path computation element) learns this information is
  outside the scope of this document.

I think that not defining the mechanism in this document is ok -- but not having one means that important parts of this specification can't work.  Please point at where such a mechanism is specified, or at least provide examples. 

The Shepherd's writeup says that "implementation plans and implementations" are known so I think that this should be an easy point to address.

[Ballot comment]
(1) §5.3.1: "The ETLD MUST be decremented at each non-delegation transit hop by either 1 or some appropriate number based on the limitations at that hop."  What is "some appropriate number"?  Please be specific.  Can you provide an example? 


(2) §7: The text about how to build the label stack is not as specific as it should be:

(2a) [nit] "The following logic could be used..."  Is it optional?

(2b) "Each RRO label sub-object SHOULD be processed starting with the label sub-object from the first downstream hop.  Any label provided by the first downstream hop MUST always be pushed on the label stack regardless of the label type."  When would the processing not start with the first downstream hop?  If the processing is not done (because of the "could" and the "SHOULD"), then how can the MUST be enforced?


(3) I find it strange (maybe even contradictory) that §9.1 (Requirements) talks about the requirements which are satisfied in this document using SHOULDs...or any Normative language at all.  It is not clear to me whether the Normative language in this section is intended to direct the behavior, or just list requirements.  I would rather see the requirements listed without Normative language being used.


(4) §9.2: "When a node that does not cater to the mandate receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object with this flag set, it MUST send a PathErr message..."  Why would a node "not cater to the mandate"?  I imagine one instance being simply that the node doesn't support the behavior specified in this document.  This document can't specify the behavior of a node that doesn't know what the new behavior is.  If there are other reasons for not complying, please be explicit.

(4a) Note that §9.4 uses a similar construct: "If the hop is not able to comply with this mandate...", which implies that there may be a reason other than not supporting the functionality.  Here as well, what are examples of reasons for the node not being able to comply?


(5) §9.4: "If the transit hop does not support this flag, it MUST act as if it does not support TE link labels."  I'm not sure if this text refers to a node not supporting this specification (see above), or to a neighbor of that node.  In either case, what does "act as if it does not support TE link labels" mean?  How can "acting" be Normatively enforced?  Does that mean that if the node supports this specification it must stop doing so (at least for the LSP)?  ??

(5a) §9.6 also talks about "the transit hop".  Please clarify there as well.

(5b) Note that the same phrase (act as if...) is also used in §5.3.1.


(6) §9.7: "The format of the ETLD Attributes TLV is shown in Figure 8."  The Figure only shows the value part of the TLV -- it would be nice to get a pointer to the place where the TLV structure is defined (rfc5420).

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

The IANA Functions Operator has completed its review of draft-ietf-mpls-rsvp-shared-labels-06. If any part of this review is inaccurate, please let us know.

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

First, in the Attribute Flags registry on the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-te-parameters/

three, new registrations are to be made as follows:

Bit No: 16
Name: TE Link Label
Attribute Flags Path: Yes
Attribute Flags Resv: No
RRO: No
ERO: No
Reference: [ RFC-to-be, Section 9.2 ]

Bit No: 17
Name: LSI-D
Attribute Flags Path: Yes
Attribute Flags Resv: No
RRO: No
ERO: Yes
Reference: [ RFC-to-be, Section 9.4 ]

Bit No: 18
Name: LSI-D-S2E
Attribute Flags Path: Yes
Attribute Flags Resv: No
RRO: No
ERO: No
Reference: [ RFC-to-be, Section 9.6 ]

Second, in the Attribute TLV Space registry on the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-te-parameters/

the temporary registration for Type: 6, ETLD will be made permanent and its reference changed to [ RFC-to-be, Section 9.7 ].

Third, a new subregistry of the existing Record Route Object Sub-object Flags registry on the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-te-parameters/

will be created. The new subregistry will be called the Record Route Label Sub-object Flags registry. The new subregistry will be managed using Standards Action as defined by RFC 8126. There are initial registrations in the new subregistry as follows:

Flag Name Reference

0x1 Global Label RFC 3209
[ TBD-at-Registration ] TE Link Label [ RFC-to-be, Section 9.3]
[ TBD-at-Registration ] Delegation Label [ RFC-to-be, Section 9.5]

Fourth, in the Sub-Codes - 24 Routing Problem subregistry of the Error Codes and Globally-Defined Error Value Sub-Codes registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at:

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

two, new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: TE link label usage failure
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Label stack imposition failure
Reference: [ RFC-to-be ]


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-12-11):

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-rsvp-shared-labels@ietf.org, mpls-chairs@ietf.org, Loa Andersson , loa@pi.nu
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Signaling RSVP-TE tunnels on a shared MPLS forwarding plane) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Signaling RSVP-TE tunnels on a
shared MPLS forwarding plane'
  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-12-11. 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


  As the scale of MPLS RSVP-TE networks has grown, so the number of
  Label Switched Paths (LSPs) supported by individual network elements
  has increased.  Various implementation recommendations have been
  proposed to manage the resulting increase in control plane state.

  However, those changes have had no effect on the number of labels
  that a transit Label Switching Router (LSR) has to support in the
  forwarding plane.  That number is governed by the number of LSPs
  transiting or terminated at the LSR and is directly related to the
  total LSP state in the control plane.

  This document defines a mechanism to prevent the maximum size of the
  label space limit on an LSR from being a constraint to control plane
  scaling on that node.  It introduces the notion of pre-installed 'per
  Traffic Engineering (TE) link labels' that can be shared by MPLS
  RSVP-TE LSPs that traverse these TE links.  This approach
  significantly reduces the forwarding plane state required to support
  a large number of LSPs.  This couples the feature benefits of the
  RSVP-TE control plane with the simplicity of the Segment Routing MPLS
  forwarding plane.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-shared-labels/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-shared-labels/ballot/

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

  https://datatracker.ietf.org/ipr/2976/
  https://datatracker.ietf.org/ipr/3265/
  https://datatracker.ietf.org/ipr/3266/
  https://datatracker.ietf.org/ipr/3036/
  https://datatracker.ietf.org/ipr/2997/

The MPLS working group request that '

    draft-ietf-mpls-rsvp-shared-labels

is published as an RFC on the Standards Track.

(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?

  We are requesting that the document is published as Proposed
  Standard.
  This is the proper type of RFC since if defines new protocol
  elements, new procedures and allocate IANA code points from

(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

  As MPLS RSVP-TE networks grows, so does the number of LSPs
  supported by network elements.  Various implementation
  recommendations have been proposed to manage the resulting
  increase in control plane state.

  The recommendations proposed to manage control plane state, have
  had no effect on the number of labels in the forwarding plane
  necessary for an LSR to support.

  This document defines a mechanism that prevent the maximum number
  an LSR may support to be a limitation on control plane scaling on
  the LSR.  The concept of pre-installed 'per TE) link labels' that
  can be shared by MPLS RSVP-TE LSPs.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  No such controversies. The WG process has been very
  straightforward.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We know of implementation plans and implementations, this was the
  reason to allocate some of the code points by early allocation.
  However we have no detailed information. We have started an
  implementation poll and will update the Write-Up when we receive
  more information.

  No expert reviews necessary.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Andersson is the Document Shepherd
  Deborah Brungard 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 (also wg chair), reviewed the document at
  the normal way points of the document, when it was first posted,
  when we did the working group adoption poll, when preparing the
  working group last call and when writing the shepherds write-up.

  This version 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 such concerns!

(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 such reviews necessary,

(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.

  No such concerns.

(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.

  All the authors and contributors has confirmed that they are
  unaware of any other IPR that relates to this document than those
  that have been disclosed.

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

  The IPR tool lists 5 IPRs against this document, however 2 of them
  are updates of IPRs disclosed against the individual document when
  it became a working group document.

  The working group were notified about all IPRs at the adoption
  poll and wglc. There has been no concerns at all.

(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 a very solid support for this specification.

(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 such threats!

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

  The document passes the nits tool clean, there is one case of a
  newer version of an ID, that is referenced.

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

  Np such reviews necessary.

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

  Yes the references are correctly split into normative and
  informative.



(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?

  All of the 8 normative references are to existing RFCs, 6 of them
  to PS and the other two BCPs.

(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 downward references.

(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 other document will have its status changed when this document
  is published.


(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 Shepherd has reviewed the IANA section as it has developed.
  All referenced IANA registries are clearly identifiable, early
  IANA allocations are included in the IANA section.
  One new sub-registry is defined (section 1.3) the allocation policy
  is clearly defined.

(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.

  No such registries.

(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.

  No such reviews necessary.