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!

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 <[e-mail]>
wrote:

> Alvaro, Hi!
>
>
>
> Please see inline (prefixed [Pavan]).
>
>
>
> Regards,
>
> Pavan
>
> On Thu, Dec 20, 2018 at 8:06 AM Alvaro Retana <[e-mail]>
> wrote:
>
>> 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.
>>
> [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.
>>
>