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

[Vishnu Pavan Beeram <[e-mail]>]

Matt, Hi!

Please see inline (prefixed Pavan)

Regards,
-Pavan

On Fri, Sep 21, 2018 at 11:47 AM Matt Hartley <[e-mail]>
wrote:

Snipping comments that have been addressed..

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

[Pavan] The draft makes an assumption that the ingress LER would use
delegation if it determines (prior to signaling) that the size of the
resulting label stack will exceed its own capabilities.  Note that the
ingress may not always be able to determine the full path of the LSP or the
full size of the resulting label stack prior to the completion of the
initial signaling sequence. In such scenarios, the draft makes the
assumption that the ingress would use automatic delegation. We’ll go ahead
and makes these assumptions explicit.

In Section 4:
OLD:
   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 or Section 6.

NEW:
   Prior to signaling the LSP, the ingress LER may determine that it
   would be unable to push a label stack containing one label for each
   hop along the path.  In some scenarios, the ingress LER may not
   have sufficient information to make that determination. In these
   cases the LER SHOULD adopt the techniques described in Section 5.


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

[Pavan] The updated text in Section 4 should make the assumption on
delegation explicit. In addition to this, we’ll go ahead and add the
following statements (to make things crystal) in Sections 5.2 and 5.3.

In Section 5.2 (Explicit Delegation):
   This option SHOULD not be used if there are loose hops in the explicit
route.

In Section 5.3 (Automatic Delegation):
   This option SHOULD be used if there are loose hops in the explicit route.


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

[Pavan] The ETLD is a HOP_ATTRIBUTES TLV in the RRO of the Path message –
it comes into play only when automatic delegation is requested. If
automatic delegation is requested, a transit hop that doesn’t support
automatic delegation MUST act like a node that doesn’t support TE link
labels. The following additional statements should remove the ambiguity (if
any).

In Section 9.2:
   A transit hop that caters to this request/mandate MUST also check
   for the presence of other Attributes Flags introduced in this
   document (Section 9.4 and Section 9.6) and process them as specified.

In Section 9.4 (Automatic Delegation):
   If the transit hop does not support this flag, it MUST act as if it
   doesn’t support TE link labels. If the use of TE link labels was
   mandated in the LSP_REQUIRED_ATTRIBUTES object, it
   MUST send a PathErr message with an error code of
   'Routing Problem (24)' and an error value of 'TE link label usage
   failure (TBD3)'.


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

[Pavan] The quoted text from RFC7570 above is specific to the ERO
subobject; it doesn’t for some reason provide similar guidance for the RRO
subobject. That said, the size of the data carried in the ETLD TLV added at
a given hop is just 4 bytes.

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

[Pavan] This is covered by the text added above in Sections 9.2 and 9.4.
We’ll go ahead and add the following statement to Section 5.3.1 to make
things crystal.

   If a node is reached and it is determined that this hop cannot
   support automatic delegation, then it MUST act as if it doesn’t
   support TE link labels.


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

[Pavan] No and No. ETLD is used only for automatic delegation.


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