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

Note: This ballot was opened for revision 07 and is now closed.

Deborah Brungard Yes

(Ben Campbell) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-12-19 for -07)
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).

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Alvaro Retana (was Discuss) No Objection

Comment (2019-02-01)
Thanks for addressing my DISCUSS.

Adam Roach No Objection

Comment (2018-12-19 for -07)
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.

Martin Vigoureux No Objection

Benjamin Kaduk No Record

Comment (2018-12-20 for -07)
[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?