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 75181129AB8; Thu, 20 Sep 2018 15:51:43 -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 1gVvZMqIjXwO; Thu, 20 Sep 2018 15:51:40 -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 CD9DD128BAC; Thu, 20 Sep 2018 15:51:39 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id k21-v6so5032567pff.11; Thu, 20 Sep 2018 15:51:39 -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=Xti0TbFHpnW9aWqJ6uBMTk2TFFmCbDVqO2s5X2xFe0o=; b=Og6NcZ/awhGIwOKI/tOMzlLTgF7x8+536Z4JdsuYi752VnwQHzbjMO8PufnKG4kEyP LVIrIjbeHokw+ULDg1p5l/Z8+7/WqTVOtPz9zGt0bSLCjVYUFu8SYf+4XHtBfGWnSrGm ZvJKSiypARwSDLqgYWj/N1Ony6DqYG+CcupJwp+CpuLoRKfvSzB7SS1AGtEjuYrLQOns hw0kVeZ7Eb/Dq1e3zAUkKYv85x46otpl5QFS/4XUV9hkKGdE3sBOTZkxUwGaIK5RELrm OWEBK0WcO5t0TGz0xbqTy2hekyqmasfU/v637PdL/EfiMASoe/p3J0vf8qpnFVKyC+FD rsww== 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=Xti0TbFHpnW9aWqJ6uBMTk2TFFmCbDVqO2s5X2xFe0o=; b=c89bhRNd3WtYy2KDgUeRUNEUFIVr1Ux7jSflxWF6nogoFBDxD3u5/AfWqdLyVokq2T /3vriyzGWWrSyKqfrMe6QqRXBTI+ghnfcCobZfbRMb6HfAtIyIeHNQoQZbqG5QJkT6yf BcLdxlaGkIneEJvfhf94qqwfejaHB1/QpAvcMznmjR/Ml6mNVvaNTh60Bl8v2ro/Izr6 TVdKYMa31ootEj4nmaXObyI85n6gfzgRS0u2BQeMsb/5CPnxPO0ZxaKGojPdI4e1YSCt cGjCXAg7tn9Sk7l/6U1ZQ76xABy0evDZ3Ol99ZuAJh5/uPu9ugsJSdbSLodVC16ibm65 wNoQ== X-Gm-Message-State: APzg51DNWm7IG2Yb+yF9hPUqwt7pSZbLzB/N4ZS9zsljmbQVsHIBv/62 YvEggVijW2rWT/7ZCg6flguJ8czoctCmJsLhWb0= X-Google-Smtp-Source: ANB0VdZsWRdEKZECjz4z+0VphseZVAdAjBJQKChYnBbZETtLi6U0ybio+5qpcJRrpXk34BHCJLN8mLVoUDJWZV/EIdk= X-Received: by 2002:a62:56d9:: with SMTP id h86-v6mr43633730pfj.229.1537483899285; Thu, 20 Sep 2018 15:51:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vishnu Pavan Beeram Date: Thu, 20 Sep 2018 18:51:27 -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="000000000000aa36410576555d49" 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: Thu, 20 Sep 2018 22:51:44 -0000 --000000000000aa36410576555d49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Woul= d > it make sense to combine the two documents so that we have a more complet= e > 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 g= et > the base technology standardized earlier. > [VPB] =E2=80=9CDifficulty=E2=80=9D is a relative concept =F0=9F=98=8A. Supp= orting 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 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 (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=E2=80=99) 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). > > 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 th= an > 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 st= atement come in? > > 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 y= ou > 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 addres= s > 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 th= e > 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 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 > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --000000000000aa36410576555d49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

=C2=A0

At the end of s= ection 4, you mention that an ingress node might want to avoid creating a s= hared-label LSP which will have a deeper label stack than it can handle by = using delegation or reverting to standard RSVP-TE. Hopefully implementation= s 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 S= HOULD 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?

=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 en= tire path and can therefore request delegation nodes to keep the label stac= k 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 expans= ion on a shared-label LSP must also act as a delegation node for the segmen= t 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.

=C2= =A0
=

Cheers

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