Re: [mpls] Adam Roach's No Objection on draft-ietf-mpls-rsvp-shared-labels-07: (with COMMENT)

Adam, Hi!

Thanks for the review!

Please see responses inline (prefixed VPB).

Regards,

Pavan

On Wed, Dec 19, 2018 at 5:09 PM Adam Roach <adam@nostrum.com> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-mpls-rsvp-shared-labels-07: No Objection
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> 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.
>

[VPB] Please see our response to Alvaro who had a similar concern. The
above text is meant to be normative. Please see if the proposal in our
response to Alvaro addresses your concern.

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

[VPB] Point taken. We'll change this to a "MUST".

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

[VPB] Please see our response to Alvaro and let us know if that addresses
your concern.

This is not a restatement of the behavior of LSP_REQUIRED_ATTRIBUTES.

>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>