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

[Vishnu Pavan Beeram <[e-mail]>]

Alvaro, Hi!



Thanks for the review!

Please see responses inline (prefixed VPB).



Regards,

Pavan

On Mon, Dec 17, 2018 at 5:32 PM Alvaro Retana <[e-mail]>
wrote:

> 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.
>
>
>
[VPB] The specification discusses a couple of delegation options -- the
explicit delegation option (Section 5.2) and the automatic delegation
option (Section 5.3). The explicit delegation option is the only one that
needs the ingress or the controller to be aware of the label stack depth
push limit of each of the transit LSRs prior to signaling. This information
is not needed when the automatic delegation option is employed -- the
limitations of each transit node are taken into account while picking the
delegation hops during the initial signaling sequence.



For the explicit delegation option, an implementation may choose to employ
any of the following mechanisms to learn the label stack depth push limit
of each LSR in the network --  ISIS (RFC8491), OSPF (RFC8476), BGP-LS
(draft-ietf-idr-bgp-ls-segment-routing-msd), PCEP
(draft-ietf-pce-segment-routing), local config (just set a global limit),
netconf/restconf/grpc using the data-model specified in
draft-ietf-teas-yang-sr-te-topo.



Please see if the addition of the following statement to the end of the
first paragraph in Section 5.2 addresses your concern:



"Examples of such a mechanism are specified in RFC8491 and RFC8476."



**


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

[VPB] We did discuss this during the WG adoption poll. The option to
decrement the ETLD by "some appropriate number" was added to let the
transit hop cater to the scenario where the ETLD value in the received PATH
message is larger than the maximum number of labels in the stack that the
hop can handle. In other words, the "limitations at that hop" reference in
the text above need not be limited to just the "push limitation", it could
include the "read limitation" as well. Consider a transit hop that can read
only 6 labels and has a local policy that mandates it to not receive any
more transport labels in the stack than it can possibly read. If this hop
receives an ETLD of 8 from the previous-hop, then it could adjust the
outgoing ETLD to 5 (thus ensuring that it can never receive any more
label-stack-entries than it can actually read).



**


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

[VPB] No. Please see if the following change addresses your concern:



OLD:

      The following logic could be used by the node constructing the label
stack:



NEW:

      The following logic is used by the node constructing the label stack:

--


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

[VPB] Please see if the following change addresses your concern:

OLD:

      Each RRO label sub-object SHOULD be processed starting with the

      label sub-object from the first downstream hop.



NEW:

      Each RRO label sub-object MUST be processed starting with the

      label sub-object from the first downstream hop.

***


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

[VPB] Point taken. Agree that the Normative language is not needed in this
section. We'll replace all occurrences of "SHOULD" in this section with
"needs to". Please see if the following changes address your concern:



[REPLACED TEXT]

   o  The Ingress of the LSP needs to have the ability to mandate/request

      the use and recording of TE link labels at all hops along the path

      of the LSP.



   o  When the use of TE link labels is mandated/requested for the path:



      *  the node recording the TE link label needs to have the ability to

         indicate if the recorded label is a TE link label.



      *  the ingress needs to have the ability to delegate label stack

         imposition by:



         +  explicitly mandating specific hops to be delegation hops

            (or)



         +  requesting automatic delegation.



      *  When explicit delegation is mandated or automatic delegation is

         requested:



         +  the ingress needs to have the ability to indicate the chosen

            stacking approach (and)



         +  the delegation hop needs to have the ability to indicate that

            the recorded label is a delegation label.

**


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

[VPB] There is a distinction that is being drawn here between an
implementation that doesn’t understand this flag and an implementation that
understands this flag but chooses not to cater to it (local policy). In the
former scenario, it goes without saying that the regular processing rules
for LSP_REQUIRED_ATTRIBUTES come into play (
https://tools.ietf.org/html/rfc5420#page-11). The text quoted above is for
the latter scenario. A transit node may support both regular RSVP-TE LSPs
and Segment Routed RSVP-TE LSPs. Local policy may determine if the node
should cater to both types or just one type.



Please see if the following change makes things clear:



OLD:

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



NEW:

   When a node that recognizes this flag but 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)'.



**


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

[VPB] The previous response should have provided some clarity on this.
Please note that as per 9.2, a node that recognizes the "TE Link Label"
Attribute Flag MUST also recognize the other Attribute Flags defined in
this document. Please see if the following change makes things clear:



OLD:

   If the hop is not able to comply with this mandate, it

   MUST send a PathErr message with an error code of 'Routing Problem

   (24)' and an error value of 'Label stack imposition failure (TBD4)'.



NEW:

   If the hop recognizes this flag but is not able to comply with this
mandate, it

   MUST send a PathErr message with an error code of 'Routing Problem

   (24)' and an error value of 'Label stack imposition failure (TBD4)'.



**


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

[VPB] This refers to a transit node that supports the "TE Link Label"
Attribute flag but does not support the automatic delegation functionality
(it does recognize the flag though). Such nodes would support "TE Link
Labels" as long as "automatic delegation" is not also requested. But if
"automatic delegation" is also requested, they would act as if they don’t
support "TE Link Labels" and use regular labels.



Would the following change make things clear?



OLD:

If the transit hop does not support this flag, it MUST act as if it does
not support TE link labels



NEW:

If the transit hop does not support this flag, it MUST act as if it does
not support TE link labels and use regular labels.

**


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

[VPB] The previous responses should have made this clear.

 **


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

[VPB] The previous responses should have made this clear.

 **


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

[VPB] We will add a reference to RFC5420 (oversight on our part) at the
place where LSP_ATTRIBUTES is first mentioned (and also add a pointer to
the TLV structure).

**


>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>