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

[Matt Hartley <[e-mail]>]

Pavan,

On Thu, Sep 20, 2018 at 7:16 PM Vishnu Pavan Beeram <[e-mail]>
wrote:

> Matt, Hi!
>
> Please see inline (prefixed VPB).
>
> Regards,
> -Pavan
>
>
> On Thu, Sep 20, 2018 at 2:25 PM Matt Hartley <[e-mail]>
> 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.
>

This is fine if you're using an LSP_REQUIRED_ATTRIBUTES object, because a
node that doesn't understand this will generate a Path-Error. But if you
use LSP_ATTRIBUTES, you can't guarantee that every node along the path will
have processed and understood this, and a node that doesn't process this
won't know it should record labels in the RRO.

Given that there seems to be a desire to use TE link labels in situations
where not all nodes support this document, I think you need to either set
the SESSION_ATTRIBUTES flag too, or explain how a node that hasn't
processed this object knows that it should record labels.

Cheers

Matt


>
>
>>
>> Cheers
>>
>> Matt
>>
>> On Wed, Sep 19, 2018 at 11:43 AM Matt Hartley <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>