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

[Alvaro Retana <[e-mail]>]

On December 20, 2018 at 7:15:52 AM, Vishnu Pavan Beeram (
[e-mail]) wrote:

Pavan:

Hi!

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

These are fine examples, and they would satisfy the point above.

However, they raise an additional one.  rfc8491 has a very specific
definition of what the Base MPLS Imposition MSD is, but that definition may
not match what is discussed here.  The intent may be the same, but the text
is different, and given the extensive discussion prior to the publication
of rfc8491, I want to make sure that we are in fact talking about the same
thing: "label stack depth push limit” doesn’t directly map to "the total
number of MPLS labels that can be imposed, including all
service/transport/special labels” [rfc8491].  I note that this document
specifically mentions just transport labels.

If the definition of the BMI-MSD is what is expected in this document,
please explicitly say so.  If not, then I think that we would need to
define a new MSD-Type for the suggestions above to be applicable.


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

It would be great if you added an explanation like that in the document.

...

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



**

I think it would be clearer if you mentioned the reason in the text: local
policy.  Maybe s/does not cater/does not cater because of local policy


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



**

Again, mentioning the reason would make it clearer.


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

**

Maybe s/support this flag/support this functionality

I still think that “acting” can’t be enforced.  Maybe s/MUST act as if it
does not support TE link labels and use regular labels/MUST NOT use TE link
labels and use regular labels instead


...

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

See above…


Thanks!!

Alvaro.