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

Matt, Hi!

Please see inline for responses (prefixed VPB).

Regards,

-Pavan

On Wed, Sep 19, 2018 at 11:44 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...
>

[VPB] Much Thanks for the review. It is never too late to send in review
comments.

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

[VPB] “Difficulty” is a relative concept 😊. Supporting facility backup
link protection on the shared forwarding plane is straight-forward – this
is discussed in Section 8.1 of the draft.  But given the nature of the
forwarding plane, we needed to define new procedures for facility backup
node protection. Delegation is just another additional aspect to consider
while defining these procedures. By the time we put together the node
protection procedures, the base draft was sufficiently cooked for an
implementation to adopt and deliver a deployable solution (note that there
are deployments out there that don’t turn on node-protection). So, we went
ahead and published a separate draft for node protection
(draft-chandra-mpls-rsvp-shared-labels-np).
The procedures in this new draft are fully backwards compatible with the
procedures discussed in the base draft. IMO, stalling the progress of the
base draft and waiting for the node protection procedures to mature seems a
tad unfair. Our (the authors’) preference would be to progress the base
draft without any references to the node protection draft and let the node
protection draft go through the WG process independently (take the natural
course).

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

[VPB] I don’t think I follow this. The last paragraph of section 4 reads:

   There MAY be local operator policy at the ingress LER that influences

   the maximum depth of the label stack that can be pushed for a Segment

   Routed RSVP-TE tunnel.  Prior to signaling the LSP, the ingress LER

   may decide that it would be unable to push a label stack containing

   one label for each hop along the path.  In this case the LER can

   choose either to not signal a Segment Routed RSVP-TE tunnel (using

   normal LSP signaling instead), or can adopt the techniques described

   in Section 5
<https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#section-5>
or Section 6
<https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#section-6>
.

All that the above text is trying to say is that in scenarios where the
ingress LER cannot handle the full label stack, it can get around this
limitation by either using the delegation approach or reverting to
traditional RSVP-TE. Where would a “SHOULD NOT/MUST NOT” statement come in?

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

[VPB] The draft doesn't make any mention of "loose-hop expansion" because
the authors didn't seen the need to add any specific text for this. There
are two types of delegation discussed in this document – Explicit
Delegation and Automatic Delegation (Sections 5.2 and 5.3). There is
nothing special about loose-hop expansion when Automatic Delegation is in
play. The node that expands the loose-hop processes the ETLD like any other
transit node as per the procedures defined in Section 5.3.1. Explicit
Delegation is meant to be used when the controller/ingress has full
visibility into the limitations of the nodes/links that constitute the path
of the LSP. If the controller/ingress does not have full visibility (as
would be the case when loose-hop paths are used), then it should just use
automatic delegation.

>
> Cheers
>
> Matt
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>