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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 18 Jan 2019 08:43:28 -0500

Alvaro, Hi!

We just uploaded a new rev (-08) for this draft. Please do go through the
diffs (
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-shared-labels-08)
and let us know if all your comments have been addressed.

Regards,
Pavan (on behalf of the authors)

On Thu, Dec 20, 2018 at 10:18 AM Vishnu Pavan Beeram <[email-masked]>
wrote:

> Alvaro, Hi!
>
>
>
> Please see inline (prefixed [Pavan]).
>
>
>
> Regards,
>
> Pavan
>
> On Thu, Dec 20, 2018 at 8:06 AM Alvaro Retana <[email-masked]>
> wrote:
>
>> On December 20, 2018 at 7:15:52 AM, Vishnu Pavan Beeram (
>> [email-masked]) 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.
>>
> [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.
>
>>
>> ----------------------------------------------------------------------
>>> 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.
>>
> [Pavan] Okay. We’ll add that.
>
>
>>
>> ...
>>
>> (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
>>
> [Pavan] Agree. We’ll make the suggested change.
>
>>
>> (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.
>>
> [Pavan] Okay. We’ll make the suggested change.
>
>>
>> (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
>>
>>
>> [Pavan] Okay. We’ll make the suggested change.
>
>> ...
>>
>> (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.
>>
>

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 23 Jan 2019 13:52:58 -0800

On January 18, 2019 at 8:43:42 AM, Vishnu Pavan Beeram (
[email-masked]) wrote:

Pavan:

Hi!

No, not completely.  See below.
...

> to as the BMI-MSD in RFC8491. We will make that explicit.

I see no place in the text where the relationship to the BMI-MSD is
explicitly made.

I see the text (in parenthesis) that you added in §5.3: "label stack depth
push limit (number of MPLS labels that can be imposed)”, but that doesn’t
make reference to either the BMI-MSD or rfc8491.  Also, the text added is
not the complete definition.  All this would make rfc8491 a Normative
reference.

Thanks!

Alvaro.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 25 Jan 2019 18:17:30 -0500

Alvaro, Hi!

Thanks for reviewing the changes.
Please see inline..

Regards,
-Pavan

On Wed, Jan 23, 2019 at 4:52 PM Alvaro Retana <[email-masked]>
wrote:

Snipped..

>> [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.
>>
>
> not the complete definition.
>

Please see if the following changes address the concern.
**
In Section 5.2

OLD:

   In order to accurately pick
   the delegation hops, the ingress needs to be aware of the label stack
   depth push limit (number of MPLS labels that can be imposed) of each
   of the transit LSRs prior to initiating the signaling sequence.
   ...
   An example of such a mechanism is specified in [RFC8491].

NEW:
   In order to accurately pick
   the delegation hops, the ingress needs to be aware of the label stack
   depth push limit (total number of MPLS labels that can be imposed,
   including all service/transport/special labels) of each of the
   transit LSRs prior to initiating the signaling sequence.
   ...
   An example of such a mechanism is specified in [RFC8491] (BMI-MSD
   advertisement).
**

>> All this would make rfc8491 a Normative reference.

Would it? Please note that the “explicit delegation” can be implemented
without needing to implement any of the standard BMI-MSD learning
technologies. The RFC8491 mechanism is just one option. As stated earlier,
an implementation may choose to employ any of the following mechanisms
besides 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.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 31 Jan 2019 22:45:46 +0100

On January 25, 2019 at 6:17:42 PM, Vishnu Pavan Beeram (
[email-masked]) wrote:

Pavan:

...

Snipped..

OLD:

NEW:

I would have preferred if a Normative reference was made to BMI-MSD to
avoid any confusion (vs copying the definition here).  That’s were I think
that rfc8491 would be Normative; not in the mechanism, but in the
definition.

In any case, I guess the way you wrote it above is ok as well.  I’ll clear
the DISCUSS when you publish an update.

Thanks!!

Alvaro.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 31 Jan 2019 20:45:14 -0500

Alvaro, Hi!

Thanks! We published an update as suggested (
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-shared-labels-09).

Regards,
Pavan

On Thu, Jan 31, 2019 at 4:45 PM Alvaro Retana <[email-masked]>
wrote:

>> I see the text (in parenthesis) that you added in §5.3: "label stack
>> depth push limit (number of MPLS labels that can be imposed)”, but that
>> doesn’t make reference to either the BMI-MSD or rfc8491.  Also, the text
>> added is not the complete definition.
>>
>