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

From: Alvaro Retana <[email-masked]>
Date: Mon, 17 Dec 2018 14:32:05 -0800

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.

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

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

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

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

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

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

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

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

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

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 20 Dec 2018 07:15:33 -0500

Alvaro, Hi!

Thanks for the review!

Please see responses inline (prefixed VPB).

Regards,

Pavan

> https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-shared-labels/
[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."

**

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

**

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

--

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

***

> requirements.  I would rather see the requirements listed without Normative

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

**

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

**

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

**

> 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

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

 **

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 20 Dec 2018 08:06:12 -0500

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

Pavan:

Hi!

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.

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

...

OLD:

   failure (TBD3)'.

NEW:

   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

OLD:

NEW:

**

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

OLD:

NEW:

**

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

...

See above…

Thanks!!

Alvaro.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 20 Dec 2018 10:18:36 -0500

Alvaro, Hi!

Please see inline (prefixed [Pavan]).

Regards,

Pavan

> define a new MSD-Type for the suggestions above to be applicable.
[Pavan] The “label stack depth push limit” is the same as what is referred
to as the BMI-MSD in RFC8491. We will make that explicit.

> It would be great if you added an explanation like that in the document.
[Pavan] Okay. We’ll add that.

> 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.
>
>
>
[Pavan] Agree. We’ll make the suggested change.

> Again, mentioning the reason would make it clearer.
[Pavan] Okay. We’ll make the suggested change.

> [Pavan] Okay. We’ll make the suggested change.