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!

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

> On January 25, 2019 at 6:17:42 PM, Vishnu Pavan Beeram (
> [e-mail]) wrote:
>
> Pavan:
>
>
> ...
>
> On Wed, Jan 23, 2019 at 4:52 PM Alvaro Retana <[e-mail]>
> wrote:
>
> Snipped..
>
>> 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.
>>
>
> 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.
>
> 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.
>