Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17F127333; Sun, 23 Sep 2018 17:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flQHpZ79V763; Sun, 23 Sep 2018 17:45:04 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203DA124BE5; Sun, 23 Sep 2018 17:45:04 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id j8-v6so8305175pff.6; Sun, 23 Sep 2018 17:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XrGGTEoLR5WgY7jWaM+4VuEk4Q20QcD+FbRQJfSivow=; b=NP6WwlIkz/al3Q1WdlyebGxmMM8YlSM0jnpxRnLkjVwQd7WdSElO4l+/nPR2cz099+ gB+Vx2d6io1J1ZBgpbbHJU0Ivy8qIMZtH9dmVcAGb01fKQDeqAVzAp4WyM5nElx08/p+ sWv1qc/laqYQNycw7cVfm9l3Av3Bi4J04TcSr8ZcHG980/r9kRsRz3GkXuSDbUmMBxLq fhGNp3h/yNZpzsb68AKPgQqkDakfe0UFqQ/9KeIs58bV1z8g+E/zABa3CyQ7ZlvrGfTR Hhlh/gptxXvHHyHohY2cITjEW8VxC66UXpaRlWECd8LmRpdiG6d9lSOCVchq7l+ja49o nE2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XrGGTEoLR5WgY7jWaM+4VuEk4Q20QcD+FbRQJfSivow=; b=mNuaGc5YMXjJIsydkRAxngJMQGctd3+Ch1LgGBIKklKhKyGVAp8pFY3Eow+sdl7qOe FM4ClteyeMoGNAIU71c0Po6KNd0KeeANJ5XZgbN8AYdxqaUMohg0Vodiuz92aDNvZm7e nX+wl+EEsQ664vUq4ylNh49xBioUimCVg+njFhAuPW7MKbnmeIeaDWaLNafE7eSorRd6 hMwIKBd7Ez3Emw5h1Ycsm4nCZya296biTF6C32NAiFx9zaUz2CkhBN8dso29aPup6cfs XTgrGIvwcvZzC0LHrjfjNmuWmj5aGJt4QNctzfkSSAIIH9mmczqOe9payG+rwGzJKL2+ M0BQ== X-Gm-Message-State: ABuFfoj0V0z6VeTRWwTCqyfl40JMOVpoJHtLmXclWnP88JxIkRyvD/3b 6FOovlgW9KPUU09rG1LwjZ/l7Felpqu3OTs1qrQ= X-Google-Smtp-Source: ACcGV608TzxG4dRnpcL/XJ0Z+VEiCGj5CAYM9MxSFigpE2kr9V1b8be5pIvWD+RYM7qgqy7eaa3062fA3embujpjLL4= X-Received: by 2002:a63:f309:: with SMTP id l9-v6mr7198335pgh.369.1537749903277; Sun, 23 Sep 2018 17:45:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vishnu Pavan Beeram Date: Sun, 23 Sep 2018 20:44:50 -0400 Message-ID: To: mhartley.ietf@gmail.com Cc: draft-ietf-mpls-rsvp-shared-labels@ietf.org, IETF MPLS List , TEAS WG Content-Type: multipart/alternative; boundary="000000000000bd015f0576934ca7" Archived-At: Subject: Re: [mpls] Comments on draft-ietf-mpls-rsvp-shared-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 00:45:07 -0000 --000000000000bd015f0576934ca7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Matt, Hi! Please see inline (prefixed Pavan) Regards, -Pavan On Fri, Sep 21, 2018 at 11:47 AM Matt Hartley 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=E2=80=99t 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 >> >> or 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 =E2=80=9CSHOULD NOT/MUST NOT=E2=80=9D= 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=E2=80=99ll g= o 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 i= f >>> 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 addr= ess >>> 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" becaus= e >> the authors didn't seen the need to add any specific text for this. Ther= e >> are two types of delegation discussed in this document =E2=80=93 Explici= t >> Delegation and Automatic Delegation (Sections 5.2 and 5.3). There is >> nothing special about loose-hop expansion when Automatic Delegation is i= n >> play. The node that expands the loose-hop processes the ETLD like any ot= her >> 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 p= ath >> 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 us= e >> 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=E2=80=99ll go ahead and add th= e 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/question= s: > > 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 =E2= =80=93 it comes into play only when automatic delegation is requested. If automatic delegation is requested, a transit hop that doesn=E2=80=99t suppo= rt automatic delegation MUST act like a node that doesn=E2=80=99t support TE l= ink 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=E2=80=99t 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=E2=80=99t 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=E2=80=99ll 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=E2=80=99t 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 >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> --000000000000bd015f0576934ca7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Matt, Hi!

Please see inline (prefixed Pava= n)
=C2=A0
Regards,
-Pavan

On Fri, Sep 21, 2018 at 11:47 AM Matt Hartley <mhartley.ietf@gmail.com> wro= te:

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 r= everting to standard RSVP-TE. Hopefully implementations will have the sense= to avoid signalling shared-label LSPs like this, but I think it might be w= orth being more assertive about this and making it a SHOULD NOT or even a M= UST NOT.

[VPB] I don=E2=80=99t think I follow this. The last paragraph of section 4 reads:

=C2=A0=C2=A0 There MAY be loca= l operator policy at the ingress LER that influences

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

=C2=A0=C2=A0 Routed RSVP-TE tu= nnel.=C2=A0 Prior to signaling the LSP, the ingress LER<= /span>

=C2=A0=C2=A0 may decide that i= t would be unable to push a label stack containing

=C2=A0=C2=A0 one label for eac= h hop along the path.=C2=A0 In this case the LER can

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

=C2=A0=C2=A0 normal LSP signal= ing instead), or can adopt the techniques described

=C2=A0=C2=A0 in Section 5 or Section 6.

=C2=A0

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 ei= ther using the delegation approach or reverting to traditional RSVP-TE. Where wo= uld a =E2=80=9CSHOULD NOT/MUST NOT=E2=80=9D statement come in?


All I'm really saying her= e is that I don't think the text you have is strong enough. Maybe add s= omething like:

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

Does that work?

[Pavan] The draft makes an assumption that the= ingress LER would use delegation if it determines (prior to signaling) tha= t the size of the resulting label stack will exceed its own capabilities.= =C2=A0 Note that the ingress may not always be able to determine the full p= ath of the LSP or the full size of the resulting label stack prior to the c= ompletion of the initial signaling sequence. In such scenarios, the draft m= akes the assumption that the ingress would use automatic delegation. We=E2= =80=99ll go ahead and makes these assumptions explicit.
=C2=A0
In Sec= tion 4:
OLD:
=C2=A0=C2=A0 Prior to signaling the LSP, the ingress LER=
=C2=A0=C2=A0 may decide that it would be unable to push a label stack c= ontaining
=C2=A0=C2=A0 one label for each hop along the path.=C2=A0 In t= his case the LER can
=C2=A0=C2=A0 choose either to not signal a Segment = Routed RSVP-TE tunnel (using
=C2=A0=C2=A0 normal LSP signaling instead),= or can adopt the techniques described
=C2=A0=C2=A0 in Section 5 or Sect= ion 6.
=C2=A0
NEW:
=C2=A0=C2=A0 Prior to signaling the LSP, the in= gress LER may determine that it
=C2=A0=C2=A0 would be unable to push a l= abel stack containing one label for each
=C2=A0=C2=A0 hop along the path= .=C2=A0 In some scenarios, the ingress LER may not
=C2=A0=C2=A0 have suf= ficient information to make that determination. In these
=C2=A0=C2=A0 ca= ses the LER SHOULD adopt the techniques described in Section 5.
=C2=A0 <= br>
=C2=A0

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 n= ode's capabilities. I think it would be worth adding some text to addre= ss this; maybe specify that a node performing loose-hop expansion on a shar= ed-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 m= ake 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 =E2=80=93 Explicit D= elegation and Automatic Delegation (Sections 5.2 and 5.3). There is nothing special a= bout loose-hop expansion when Automatic Delegation is in play. The node that exp= ands 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 use= d 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 use= d), then it should just use automatic delegation.

=

What you've said here assumes that del= egation 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 tu= nnel with loose hops, and then getting back a path with a label stack that&= #39;s too big for it to handle.
[Pavan] The updated text in Section 4 should make the assumptio= n on delegation explicit. In addition to this, we=E2=80=99ll go ahead and a= dd the following statements (to make things crystal) in Sections 5.2 and 5.= 3.
=C2=A0
In Section 5.2 (Explicit Delegation):
=C2=A0=C2=A0 This = option SHOULD not be used if there are loose hops in the explicit route.=C2=A0
In Section 5.3 (Automatic Delegation):
=C2=A0=C2=A0 This opti= on SHOULD be used if there are loose hops in the explicit route.
<= div>

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 bec= ome a delegation node. What if it can't (or doesn't want to)? Shoul= d we have a path-error for this?

[Pavan] The ETLD is a HOP_ATTRIBUTES TLV in the RRO of the Path mes= sage =E2=80=93 it comes into play only when automatic delegation is request= ed. If automatic delegation is requested, a transit hop that doesn=E2=80=99= t support automatic delegation MUST act like a node that doesn=E2=80=99t su= pport TE link labels. The following additional statements should remove the= ambiguity (if any).
=C2=A0
In Section 9.2:
=C2=A0=C2=A0 A transit= hop that caters to this request/mandate MUST also check
=C2=A0=C2=A0 fo= r the presence of other Attributes Flags introduced in this
=C2=A0=C2=A0= document (Section 9.4 and Section 9.6) and process them as specified.
= =C2=A0
In Section 9.4 (Automatic Delegation):
=C2=A0=C2=A0 If the tra= nsit hop does not support this flag, it MUST act as if it
=C2=A0=C2=A0 = doesn=E2=80=99t support TE link labels. If the use of TE link labels was =C2=A0=C2=A0 mandated in the LSP_REQUIRED_ATTRIBUTES object, it
=C2=A0=C2=A0 MUST send a PathErr message with an error code of
= =C2=A0=C2=A0 'Routing Problem (24)' and an error value of 'TE l= ink label usage
=C2=A0=C2=A0 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 c= ombined with other stuff? I think it would be worth adding something to exp= licitly 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=E2=80=99t for som= e reason provide similar guidance for the RRO subobject. That said, the siz= e of the data carried in the ETLD TLV added at a given hop is just 4 bytes.=

I think it wou= ld be worth adding some text to say what should happen with nodes that don&= #39;t understand the ETLD, and in particular what happens when a node recei= ves an ETLD of 1 but doesn't understand it.
=C2=A0
[Pavan] This is covered by the text added above in= Sections 9.2 and 9.4. We=E2=80=99ll go ahead and add the following stateme= nt to Section 5.3.1 to make things crystal.
=C2=A0
=C2=A0=C2=A0 If a = node is reached and it is determined that this hop cannot
=C2=A0=C2=A0 s= upport automatic delegation, then it MUST act as if it doesn=E2=80=99t
= =C2=A0=C2=A0 support TE link labels.
=C2=A0

Can nodes other than the ingress introduce an ETLD in= to 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 del= egation.
=C2=A0
<= div dir=3D"ltr">

Cheers
=

Matt
=C2=A0
=

=C2= =A0

Cheers

Matt=
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--000000000000bd015f0576934ca7--