[mpls] Comments on draft-ietf-mpls-rsvp-shared-labels

[Matt Hartley <[e-mail]>]

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