Re: [Teas] Comments on draft-ietf-mpls-rsvp-shared-labels

Matt, Hi!

Please see inline (prefixed VPB).

Regards,
-Pavan

On Thu, Sep 20, 2018 at 2:25 PM Matt Hartley <mhartley.ietf@gmail.com>
wrote:

> One more thing...
>
> Obviously none of this works unless you have label recording in the RRO.
> That's requested in the session attribute flags (0x02). Should we add a
> line to say that this MUST be set if you want to use shared labels?
>

[VPB] Yes, it is obvious that label recording is mandatory. Please see the
text in Section 9.2.

   Bit Number 16 (Early allocation by IANA): TE Link Label

   The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES

   object of a Path message indicates that the ingress has requested/

   mandated the use and *recording* of TE link labels at all hops along

   the path of this LSP.

Label recording is requested/mandated by setting the “TE Link Label” bit in
the Attribute Flags TLV of the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES
object of a Path message. So, even if a PATH message comes in without the
0x02 flag set in the SESSION_ATTRIBUTES object and with the above bit set
in the Attribute Flags TLV, the implementation should treat it as a label
recording request/mandate.

>
> Cheers
>
> Matt
>
> On Wed, Sep 19, 2018 at 11:43 AM Matt Hartley <mhartley.ietf@gmail.com>
> wrote:
>
>> Authors,
>>
>> A couple of comments on this. Apologies for leaving it until WGLC, but I
>> hadn't read the draft previously...
>>
>> It's fairly clear while reading the draft that delegating label stack
>> imposition makes node-protection... difficult. The draft explicitly
>> declines to address the issue, but I see that we now have
>> draft-chandra-mpls-rsvp-shared-labels-np which addresses this issue. Would
>> it make sense to combine the two documents so that we have a more complete
>> shared-label solution? I think it would be better if we could... but this
>> is more of a preference on my side if the authors feel they'd prefer to get
>> the base technology standardized earlier.
>>
>> At the end of section 4, you mention that an ingress node might want to
>> avoid creating a shared-label LSP which will have a deeper label stack than
>> it can handle by using delegation or reverting to standard RSVP-TE.
>> Hopefully implementations will have the sense to avoid signalling
>> shared-label LSPs like this, but I think it might be worth being more
>> assertive about this and making it a SHOULD NOT or even a MUST NOT.
>>
>> Something the draft doesn't address at all (unless I missed it) is how
>> this works with loose-hop expansion. There seems to be an implicit
>> assumption that the ingress node calculates the entire path and can
>> therefore request delegation nodes to keep the label stack manageable if
>> need be, but once loose hops are in play this is no longer possible and you
>> could quite easily end up with a label stack that exceeds the ingress
>> node's capabilities. I think it would be worth adding some text to address
>> this; maybe specify that a node performing loose-hop expansion on a
>> shared-label LSP must also act as a delegation node for the segment of the
>> path that it expands, although there are other solutions too.
>>
>> Cheers
>>
>> Matt
>>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>