[mpls] Alvaro Retana's Discuss on draft-ietf-mpls-rsvp-shared-labels-07: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-rsvp-shared-labels-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-shared-labels/



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


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