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

Matt, Hi!

Please see inline (prefixed Pavan).

Regards,

-Pavan

On Fri, Sep 21, 2018 at 11:05 AM Matt Hartley <mhartley.ietf@gmail.com>
wrote:

> Pavan,
>
> On Thu, Sep 20, 2018 at 7:16 PM Vishnu Pavan Beeram <vishnupavan@gmail.com>
> wrote:
>

Snipped..

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

[Pavan] Okay. I see that an explicit statement is needed to cover
implementations that do not set this SESSION_ATTRIBUTES flag for
unprotected LSPs (no issues with LSPs requesting local protection). We’ll
go ahead and add the following statement in Section 9.2:

   An ingress LER that sets this bit MUST also set the "label recording

   desired" flag in the SESSION_ATTRIBUTE object.

>
> Cheers
>
> Matt
>
>
>>
>>
>>>
>>> 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
>>>
>>