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

[Matt Hartley <[e-mail]>]

Pavan,

Thanks for the reply! Inline:

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

> Matt, Hi!
>
>
>
> Please see inline for responses (prefixed VPB).
>
>
>
> Regards,
>
> -Pavan
>
>
> On Wed, Sep 19, 2018 at 11:44 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...
>>
>
> [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).
>

OK. That's more-or-less what I was getting at in my reply to Loa yesterday.
If there are already implementations without node protection out there then
I'm fine with prioritizing those practical considerations and progressing
this draft as it stands over getting to a more elegant end-product :)


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

All I'm really saying here is that I don't think the text you have is
strong enough. Maybe add something like:

The ingress LSR SHOULD NOT signal a Segment Routed RSVP-TE LSP without
either requesting or assigning delegation nodes if the size of the
resulting label stack will exceed its own capabilities.

Does that work?


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

What you've said here assumes that delegation is in play. It may not be, if
the ingress node doesn't request it. I see nothing in the draft that
prevents an ingress node signaling a tunnel with loose hops, and then
getting back a path with a label stack that's too big for it to handle.

While I was re-reading the ETLD stuff, I had some other thoughts/questions:

If a node receives an ETLD of 1, that means it has to become a delegation
node. What if it can't (or doesn't want to)? Should we have a path-error
for this?

Section 2.1 of RFC 7570 says:

   The size of the ERO subobject limits the
   size of the Hop Attributes TLV to 250 bytes.  The typical size of
   currently defined and forthcoming LSP_ATTRIBUTE TLVs applicable to a
   specific hop (WSON_SIGNALING, Objective Function (OF), and Metric) is
   not foreseen to exceed this limit.

Does the addition of the ETLD cause issues here, if combined with other
stuff? I think it would be worth adding something to explicitly address
this, even if just to say there's no problem (assuming that's true... I
haven't attempted to figure it out myself)

I think it would be worth adding some text to say what should happen with
nodes that don't understand the ETLD, and in particular what happens when a
node receives an ETLD of 1 but doesn't understand it.

Can nodes other than the ingress introduce an ETLD into the Path message if
the ingress node doesn't? In particular, can an explicitly-allocated
delegation node do this?

Cheers

Matt


>
>
>>
>> Cheers
>>
>> Matt
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>