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

From: Matt Hartley <[email-masked]>
Date: Wed, 19 Sep 2018 11:43:52 -0400

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

---

From: Matt Hartley <[email-masked]>
Date: Thu, 20 Sep 2018 14:25:10 -0400

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 <[email-masked]>
wrote:

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 20 Sep 2018 18:51:27 -0400

Matt, Hi!

Please see inline for responses (prefixed VPB).

Regards,

-Pavan

> hadn't read the draft previously...

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

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

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 20 Sep 2018 19:15:53 -0400

Matt, Hi!

Please see inline (prefixed VPB).

Regards,
-Pavan

> line to say that this MUST be set if you want to use shared labels?

[VPB] Yes, it is obvious that label recording is mandatory. Please see the
text in Section 9.2.

   Bit Number 16 (Early allocation by IANA): TE Link Label

   The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES

   object of a Path message indicates that the ingress has requested/

   mandated the use and *recording* of TE link labels at all hops along

   the path of this LSP.

Label recording is requested/mandated by setting the “TE Link Label” bit in
the Attribute Flags TLV of the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES
object of a Path message. So, even if a PATH message comes in without the
0x02 flag set in the SESSION_ATTRIBUTES object and with the above bit set
in the Attribute Flags TLV, the implementation should treat it as a label
recording request/mandate.

> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Matt Hartley <[email-masked]>
Date: Fri, 21 Sep 2018 11:04:50 -0400

Pavan,

On Thu, Sep 20, 2018 at 7:16 PM Vishnu Pavan Beeram <[email-masked]>
wrote:

> Label recording is requested/mandated by setting the “TE Link Label” bit
> in the Attribute Flags TLV of the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES

This is fine if you're using an LSP_REQUIRED_ATTRIBUTES object, because a
node that doesn't understand this will generate a Path-Error. But if you
use LSP_ATTRIBUTES, you can't guarantee that every node along the path will
have processed and understood this, and a node that doesn't process this
won't know it should record labels in the RRO.

Given that there seems to be a desire to use TE link labels in situations
where not all nodes support this document, I think you need to either set
the SESSION_ATTRIBUTES flag too, or explain how a node that hasn't
processed this object knows that it should record labels.

Cheers

Matt

---

From: Matt Hartley <[email-masked]>
Date: Fri, 21 Sep 2018 11:46:50 -0400

Pavan,

Thanks for the reply! Inline:

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

> ahead and published a separate draft for node protection (draft-chandra-mpls-rsvp-shared-labels-np).

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

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

> would be the case when loose-hop paths are used), then it should just use

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 21 Sep 2018 18:41:16 -0400

Matt, Hi!

Please see inline (prefixed Pavan).

Regards,

-Pavan

> On Thu, Sep 20, 2018 at 7:16 PM Vishnu Pavan Beeram <[email-masked]>

Snipped..

> processed this object knows that it should record labels.

[Pavan] Okay. I see that an explicit statement is needed to cover
implementations that do not set this SESSION_ATTRIBUTES flag for
unprotected LSPs (no issues with LSPs requesting local protection). We’ll
go ahead and add the following statement in Section 9.2:

   An ingress LER that sets this bit MUST also set the "label recording

   desired" flag in the SESSION_ATTRIBUTE object.

>>>> A couple of comments on this. Apologies for leaving it until WGLC, but
>>>> I hadn't read the draft previously...
>>>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 23 Sep 2018 20:44:50 -0400

Matt, Hi!

Please see inline (prefixed Pavan)

Regards,
-Pavan

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

Snipping comments that have been addressed..

> resulting label stack will exceed its own capabilities.

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

> 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

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

> node. What if it can't (or doesn't want to)? Should we have a path-error

[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)'.

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

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

---

From: Matt Hartley <[email-masked]>
Date: Mon, 24 Sep 2018 14:02:10 -0400

Pavan,

Thanks for the reply. The various changes/additions look good to me, except
that you should probably expand "doesn't" to "does not" when they go in the
document. One last nit...

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

Do we need to say that explicitly? I don't think a transit node introducing
an ETLD would do much harm, but if you don't want/expect it to happen then
it might be worth putting that in just to close the loophole.

Cheers

Matt

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 24 Sep 2018 23:04:21 -0400

Matt, Hi!

Great that we are in sync now. Please see inline for the response (prefixed
VPB) on the last open comment.

Regards,
-Pavan

On Mon, Sep 24, 2018 at 2:02 PM Matt Hartley <[email-masked]>
wrote:

Snipped..

> Do we need to say that explicitly? I don't think a transit node
> introducing an ETLD would do much harm, but if you don't want/expect it to
> happen then it might be worth putting that in just to close the loophole.
>
> [VPB] I don’t see the need for any additional text. We have explicit text
in Section 9.7 stating that ETLD is used only if Automatic Delegation is
requested in the LSP_ATTRIBUTES. LSP_ATTRIBUTES is included in the PATH
message at the ingress.

---

From: Matt Hartley <[email-masked]>
Date: Tue, 25 Sep 2018 10:16:19 -0400

OK. That works for me!

Cheers

Matt

On Mon, Sep 24, 2018 at 11:04 PM Vishnu Pavan Beeram <[email-masked]>
wrote:

> Matt, Hi!
>
> Great that we are in sync now. Please see inline for the response
> (prefixed VPB) on the last open comment.
>
> Regards,
> -Pavan
>
>> [VPB] I don’t see the need for any additional text. We have explicit
> text in Section 9.7 stating that ETLD is used only if Automatic Delegation
> is requested in the LSP_ATTRIBUTES. LSP_ATTRIBUTES is included in the PATH
> message at the ingress.
>
>
>> Cheers
>>
>> Matt
>>
>