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

[Matt Hartley <[e-mail]>]

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?

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
>