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

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

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.

Thanks for addressing my DISCUSS.