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

[Alvaro Retana <[e-mail]>]

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

Pavan:

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.

No, not completely.  See below.
...


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

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.