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 BF2C312777C; Fri, 21 Sep 2018 08:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 xIIwFYbVRZk9; Fri, 21 Sep 2018 08:47:03 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 67BA3130E5D; Fri, 21 Sep 2018 08:47:03 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id b129-v6so6221599pga.13; Fri, 21 Sep 2018 08:47:03 -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=YgxdWAwm6VzZFOiaODR0gMQYUReE4pOBk+VYOTP7RyM=; b=eWRfyOSVITBqXzUXSfhnXDSuANvAifNpJpnZqCwqmC9WqmMjGxcKt3xxmAIxNwH5gx JTTCJ0Wgz1PlS2NrreB1gCaj8k5/3xjnVe5CAvyIIkjHtPpasH++C5Di4+MDAFsiacR0 r1uTIInaWQ53TSxIF1/xT0KmtK9jndlKHqoKcr23Hi9W8uyZnDuTMijrzlexdBqN/xv+ VdrsE2oYOV1+qM1JtZH+DcLxRK644t1y5940DX+Ejnf47er/O0EgqVT5NL0LQteHt88Z E0IWhqWtZIR1x1GpwKbm4nC6NCCv4jfSeHtT/hKbEPDy/FEWW7BVLEzyCW6f31YDdyb0 n0OA== 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=YgxdWAwm6VzZFOiaODR0gMQYUReE4pOBk+VYOTP7RyM=; b=tWSx/ksFiwGD/WVIkdMzIEvmx62eosFADKh3JsDGg41tUJDV8z3oM+93mYyP59zYSe 2ut/KM/Auc/O5RR0HxiUFHdNiImLDUkyx8a5ghIGm7yj5WO7W/fxU6kC/kMYdwOfFvB9 +sjxqmh9zNg/6pD8PjBa+XUT4u3R6ej3TbUgnX5cRhxC7tBs4aU1njgbduFKJ4ratguc FQ45DrQnIzrSO8sRqWNyeuNsbm4ru3E6zBDQJ8cq3N9knHlMrQuFkOPdh9FlHLDNysER 8SzcWBAl0wd/RxE9t0ddkDFu9cbCK2qPsjPrzKh6HYZi/8oB5VaMWsnZnYSpfy5zUUhH xQQg== X-Gm-Message-State: APzg51B3XqeOEm8/+cB4vxEBplFB4bny5m7nR86XRIt8kCNfGDHb3wsD NlSysNN1wxkZJn2vUnS4LfP/HHQLlD+24g3DnuU= X-Google-Smtp-Source: ANB0VdY7Zi7O4Gz0lXq9WxycDOrLuwXxOGeHm2lNGWun97P8uFrafDdh/VzTOh8oRVzo7nxno67cUTdyde8NwVDyEww= X-Received: by 2002:a62:59d5:: with SMTP id k82-v6mr46674832pfj.143.1537544822892; Fri, 21 Sep 2018 08:47:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matt Hartley Date: Fri, 21 Sep 2018 11:46:50 -0400 Message-ID: To: vishnupavan@gmail.com Cc: draft-ietf-mpls-rsvp-shared-labels@ietf.org, mpls@ietf.org, teas@ietf.org Content-Type: multipart/alternative; boundary="000000000000fece000576638c2a" 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: Fri, 21 Sep 2018 15:47:07 -0000 --000000000000fece000576638c2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pavan, Thanks for the reply! Inline: On Thu, Sep 20, 2018 at 6:51 PM Vishnu Pavan Beeram wrote: > Matt, Hi! > > > > Please see inline for responses (prefixed VPB). > > > > Regards, > > -Pavan > > > On Wed, Sep 19, 2018 at 11:44 AM Matt Hartley > 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. Wou= ld >> it make sense to combine the two documents so that we have a more comple= te >> shared-label solution? I think it would be better if we could... but thi= s >> is more of a preference on my side if the authors feel they'd prefer to = get >> the base technology standardized earlier. >> > > [VPB] =E2=80=9CDifficulty=E2=80=9D is a relative concept =F0=9F=98=8A. Su= pporting facility backup > link protection on the shared forwarding plane is straight-forward =E2=80= =93 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 ther= e > are deployments out there that don=E2=80=99t turn on node-protection). So= , we went > ahead and published a separate draft for node protection (draft-chandra-m= pls-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=E2=80=99) preference would be to progress th= e base > draft without any references to the node protection draft and let the nod= e > protection draft go through the WG process independently (take the natura= l > 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 t= han >> 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? > 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 addre= ss >> 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 t= he >> 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 =E2=80=93 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 oth= er > 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 pa= th > 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 >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > --000000000000fece000576638c2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Pavan,

Thanks for the reply!= Inline:

On Thu, S= ep 20, 2018 at 6:51 PM Vishnu Pavan Beeram <vishnupavan@gmail.com> wrote:

Matt, Hi!

=C2=A0

Please see inline for responses (prefixed VPB).

=C2=A0

Regards,<= /p>

-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...
<= /blockquote>

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

=C2=A0
=

It's fairly clear while reading the draf= t 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 com= plete 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 pref= er to get the base technology standardized earlier.

[VPB] =E2=80=9CDifficulty=E2=80=9D is a relative concept =F0=9F=98=8A. Support= ing facility backup link protection on the shared forwarding plane is straight-forward =E2=80=93 thi= s is discussed in Section 8.1 of the draft.=C2=A0 But given the nature of the forwarding plane, we needed to define new procedures for facility backup node protection. Delegation is just another additional aspe= ct to consider while defining these procedures. By the time we put together th= e 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=E2=80=99t turn on node-protection). So, = we went ahead and published a separate draft for node protection (draf= t-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 b= ase draft and waiting for the node protection procedures to mature seems a tad unfair. Our (the authors=E2=80=99) preference would be to progress the base= draft without any references to the node protection draft and let the node protec= tion draft go through the WG process independently (take the natural course).


OK. That's m= ore-or-less what I was getting at in my reply to Loa yesterday. If there ar= e already implementations without node protection out there then I'm fi= ne with prioritizing those practical considerations and progressing this dr= aft as it stands over getting to a more elegant end-product :)
=C2=A0
At the end of section 4, you mention that an ingress node might wa= nt to avoid creating a shared-label LSP which will have a deeper label stac= k than it can handle by using delegation or reverting to standard RSVP-TE. = Hopefully implementations will have the sense to avoid signalling shared-la= bel LSPs like this, but I think it might be worth being more assertive abou= t 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:

=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?
=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 assumpt= ion that the ingress node calculates the entire path and can therefore requ= est delegation nodes to keep the label stack manageable if need be, but onc= e loose hops are in play this is no longer possible and you could quite eas= ily end up with a label stack that exceeds the ingress node's capabilit= ies. I think it would be worth adding some text to address this; maybe spec= ify that a node performing loose-hop expansion on a shared-label LSP must a= lso act as a delegation node for the segment of the path that it expands, a= lthough there are other solutions too.
<= br>

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

While I was r= e-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 757= 0 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)

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

Can nodes other than the ingress introduc= e an ETLD into the Path message if the ingress node doesn't? In particu= lar, can an explicitly-allocated delegation node do this?

Cheers

Matt
=C2=A0

=C2= =A0
=

Cheers

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