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 129C812956B; Tue, 30 May 2017 21:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 A25pHxPD7OmZ; Tue, 30 May 2017 21:29:54 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 28D45129B4C; Tue, 30 May 2017 21:29:53 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id o12so9312393iod.3; Tue, 30 May 2017 21:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vIpN6NuOAg+1gj5dAhyaEePJpGe/aksfkZfRdFRkIp0=; b=O00LiUD5FYhvBWT4YulTDMiYhzsYSlCPI/a/UN9Yhj32ovVEcnzXB3yCVBPt9syhvv gSzY6dc3Z7uzBlGx/lDRUv2TFXJNqtHxm0FGb6c+IxQjvMQVT2OchDY5VZSFjvneQ7Gk XvOHnlcfYUNsAaK3lksw5raMAofDbNKTkvJuPP5wuqNCX1JeVW5rFDdZaK/QxxiehZDg EWrZ8uzoyERrSIwtsSH07b8czRR5q6ki9spaSx9JXJwalLTnARsEApBuFEPnCTK7bv69 rEYYvEtM/95kGy2yrTjkQNYEm8GPmq9eZRhZxHTOsXULLGdyz1Seqcr9dyJZIqwlft20 9osA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vIpN6NuOAg+1gj5dAhyaEePJpGe/aksfkZfRdFRkIp0=; b=D1+oB3NqIf0lka6PG5bUYCQjEXzzf4QhcY7WBGOTqx1E8JGesR/c1TpTdqpAhmY+uS xqI3oCiDiHA/c+GoJP4r0fVv9eBm7pD+6/5CPNPFiDCDVDKuMMKNLglHHz69SZKt326/ 16GnqUV2wgJMh2KqzApnRh7TFq46OS/KhGHPpPjH0j1JUuy/Mddmah+TZoiKHs4t+wDU iyF+rPmOdM5VbkMCWpARDRLYr4JGPHWqua4lhIA+7zwp4iiDjVxs2EfqeSTyfIA5DZIG fQczoWmob1iwgXMIjXeyvZflIm8nALuMWzoTfQptUtW3/ZGTdVAna3S3exWigOoWdOd+ 1nqg== X-Gm-Message-State: AODbwcBxjDcgx099NWVeOL/7rvAIJSpPyYsNpd7JCRhHZH5Bt2tUQouL t7JzlgVjlZ0aoUjY1kBEjgkxqseAiw== X-Received: by 10.157.82.87 with SMTP id q23mr10271477otg.52.1496204993147; Tue, 30 May 2017 21:29:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Tue, 30 May 2017 21:29:52 -0700 (PDT) In-Reply-To: <18E37CDD-D0D0-4BE3-99AF-44E5BADCAD5D@cisco.com> References: <18E37CDD-D0D0-4BE3-99AF-44E5BADCAD5D@cisco.com> From: Greg Mirsky Date: Wed, 31 May 2017 12:29:52 +0800 Message-ID: To: Carlos Pignataro Cc: "n.leymann@telekom.de" , mpls , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="f403043c4bec20bb5b0550ca5fac" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 04:29:57 -0000 --f403043c4bec20bb5b0550ca5fac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, we clearly have different interpretation of what operational simplicity means. Of course, someone may come up with mechanism to monitor the reverse path of the BFD session that was set according to BFD Reverse Path TLV but I don't see that neither necessary, nor helpful because that may hide from an operator real failure. Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume that authors followed in the path of reasoning set by RFC 4379 (now RFC 8029). RFC 8029 defines procedures to verify correlation between the MPLS data plane and control plane. In example in Section 3.2 we see that listing all FECs is optional and it is perfectly valid to include single FEC that characterizes the outer MPLS label. Using the same approach in RFC 7110, in my opinion, was not only right but necessary. But for case of controlling the reverse direction of a BFD session that seems unnecessary. Additionally, RFC 7110 allows operator to pass the right for the final selection of the return path for Echo Reply to the egress node, to the responder. That may be useful for Echo Request/Reply as the egress returns information on how it concluded the selection process based on received Reply Path TLV. For BFD Reverse Path TLV, egress uses Return Code and Return Sub-code in Echo Reply to indicate whether the requested path is available to the egress node. If the path is not available, then the operator may send another request in LSP Ping using BFD Reverse Path TLV. Regards, Greg On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro wrote: > Greg, > > Anytime =E2=80=94 I wanted to reply so that there was at least one non-au= thor > message about it. You and I have very different views on what is a > technical concern. > > For example this comment describes a specific technical concern: > * =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D > > Basically, the document says that the return path cannot have a FEC Stack > (e.g., nested FECs or a Tunnel or...). It is not clear why. > Basically it flattens MPLS to one label on return. > > In contrast, RFC 7110 allows for multiple FECs: > > Reply Path: It is used to describe the return path that an echo > reply will be send along. It is variable in length and can > contain zero, one or more Target FEC sub-TLVs [RFC4379]. > > A second technical issue: > * =E2=80=9C This approach assumes that FECs do not ever change=E2=80=A6.= =E2=80=9D > > I find the response of =E2=80=9Cpunt it to the operator=E2=80=9D complete= unsatisfactory. > We are trying to reduce OpEx, not build tools that put the burden on > operators. > > Basically, the root cause stems from the fact that RFC 7110 uses a return > path construct for a response immediate sent and elicited by the reply, > whereas your draft attempts to mimic the method but for a protocol in whi= ch > there is a bootstrapping, and after that, no mechanism for update althoug= h > the underlying network can change. > > This proposal as it is right now, basically makes an existing protocol > more brittle than it was before, and the network operations more complex. > > Another technical concern, the description in Section 4. And then there= =E2=80=99s > also the indication of IPR but a conflicting message from one of the > authors. > > Please note I was not making specific suggestions =E2=80=94 technical or > editorial. Just pointing out that there are technical issues with this > document. > > Technically. > > =E2=80=94 Carlos. > > On May 25, 2017, at 10:26 AM, Greg Mirsky wrote: > > Dear Carlos, > thank you for taking two minutes to write the message. From it all I've > found only one concern that, in my view, may be considered technical. Thu= s > I'll bring it to the forefront and will try to explain how the situation > may be handled. > You wrote: > 1. This approach assumes that FECs do not ever change. A reverse path is > instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens i= f paths > change?!? If a return tunnel is suddenly deleted from underneath? > I consider it to be the case that should be handled by properly operating > the network rather then auto-discovering it and auto-recovering. I hardly > believe that a tunnel may be "suddenly deleted" without the operator bein= g > aware of that. And if that is the case, then the operator may proactively > re-signal return path for those BFD sessions that may be affected by the > planned change in the network. Even more, BFD sessions to decrease chance > of receiving false negative during period the remote BFD peer switches to > new recommended path. > > Thank you for the editorial suggestion to consider renaming the section. > We'll discuss and share our proposal to improve the wording. > > Others may decide to respond to the rest of your message. There's nothing > of technical substance, as I see it. > > Regards, > Greg > > On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Nic, >> >> I do not support advancing this document in its current form. It has man= y >> technical deficiencies, some of which are listed and described below. >> >> I also believe your WGLC note should have been much more detailed and >> comprehensive. >> >> I believe this is the 3rd WGLC on this document, correct? (That gives a >> new meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also b= een clarified in >> the WGLC email, with a much more clear explanation and comprehensive set= of >> details of how concerns were discussed and addressed. >> >> > The authors have updated draft-ietf-mpls-bfd-directed and think that >> the draft is ready for WGLC. >> >> I am very concerned that there was no discussion on the list of any of >> those changes. The authors believe the draft is ready =E2=80=94 do you = believe so >> as well, Nic? Was a shepherd review performed and is that available? >> >> > Please note that draft-ietf-mpls-bfd-directed did not pass the >> > previous working group last call, because of an IPR disclosure: >> >> Is that the 1st or 2nd WGLC? I think this statement is an >> oversimplification. There were many technical concerns. >> >> Anyway, scanning through this document, some technical issues: >> >> 1. This approach assumes that FECs do not ever change. A reverse path is >> instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens = if paths >> change?!? If a return tunnel is suddenly deleted from underneath? >> 2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any othe= r non-MPLS case? This >> points to the fact of lack of review and editorial sloppiness. >> 3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV= .=E2=80=9D =E2=80=94 so >> basically, no Tunnels can be return path?!? >> 4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way t= hat does not make >> sense. >> >> Please note, this is not an exhaustive list, but a 2 minute scan through >> the doc. >> >> Thanks! >> >> Carlos. >> >> >> > On May 24, 2017, at 2:33 AM, n.leymann@telekom.de >> wrote: >> > >> > Dear Working Group, >> > >> > The authors have updated draft-ietf-mpls-bfd-directed and think that >> the draft is ready for WGLC. >> > Therefore this e-mail starts a WG LC which will end on the 7th of June= . >> > >> > Please note that draft-ietf-mpls-bfd-directed did not pass the >> > previous working group last call, because of an IPR disclosure: >> > >> > https://datatracker.ietf.org/ipr/2892/ >> > >> > The authors have updated the draft and they believe that the IPR is no >> longer in scope. >> > Please notify the list if you still think the IPR is an issue and >> please state if you think it >> > is OK to continue with the publication of this document. >> > >> > Best regards >> > >> > Nic >> > >> > >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > > --f403043c4bec20bb5b0550ca5fac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
we clearly have different interpretation of= what operational simplicity means. Of course, someone may come up with mec= hanism to monitor the reverse path of the BFD session that was set accordin= g to BFD Reverse Path TLV but I don't see that neither necessary, nor h= elpful because that may hide from an operator real failure.
R= egarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume that = authors followed in the path of reasoning set by RFC 4379 (now RFC 8029). R= FC 8029 defines procedures to verify correlation between the MPLS data plan= e and control plane. In example in Section 3.2 we see that listing all FECs= is optional and it is perfectly valid to include single FEC that character= izes the outer MPLS label. Using the same approach in RFC 7110, in my opini= on, was not only right but necessary. But for case of controlling the rever= se direction of a BFD session that seems unnecessary.
Additionall= y, RFC 7110 allows operator to pass the right for the final selection of th= e return path for Echo Reply to the egress node, to the responder. That may= be useful for Echo Request/Reply as the egress returns information on how = it concluded the selection process based on received Reply Path TLV. For BF= D Reverse Path TLV, egress uses Return Code and Return Sub-code in Echo Rep= ly to indicate whether the requested path is available to the egress node. = If the path is not available, then the operator may send another request in= LSP Ping using BFD Reverse Path TLV.

Regards,
Greg

On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro &= lt;cpignata@cisco.c= om> wrote:
Greg,

Anytime =E2=80=94 I wanted to = reply so that there was at least one non-author message about it.=C2=A0 You= and I have very different views on what is a technical concern.
=
For example this comment describes a specific technical conc= ern:
* =E2=80=9CExactly one sub-TLV MUST be included in the Rever= se Path TLV.=E2=80=9D

Basically, the document says= that the return path cannot have a FEC Stack (e.g., nested FECs or a Tunne= l or...). It is not clear why.=C2=A0
Basically it flattens MPLS t= o one label on return.

In contrast, RFC 7110 allow= s for multiple FECs:

=C2=A0 =C2=A0Reply Path:= =C2=A0It is used to describe the return path that an echo
=C2=A0= =C2=A0 =C2=A0 reply will be send along.=C2=A0 It is variable in length and= can
=C2=A0 =C2=A0 =C2=A0 contain zero, one or more Target FEC su= b-TLVs [RFC4379].

A second technical issue:<= /div>
* =E2=80=9C This approach assumes that FECs do not ever change=E2= =80=A6.=E2=80=9D

I find the response of =E2=80=9Cp= unt it to the operator=E2=80=9D complete unsatisfactory. We are trying to r= educe OpEx, not build tools that put the burden on operators.
Basically, the root cause stems from the fact that RFC 7110 use= s a return path construct for a response immediate sent and elicited by the= reply, whereas your draft attempts to mimic the method but for a protocol = in which there is a bootstrapping, and after that, no mechanism for update = although the underlying network can change.

This p= roposal as it is right now, basically makes an existing protocol more britt= le than it was before, and the network operations more complex.
<= br>
Another technical concern, the description in Section 4. And = then there=E2=80=99s also the indication of IPR but a conflicting message f= rom one of the authors.

Please note I was not maki= ng specific suggestions =E2=80=94 technical or editorial. Just pointing out= that there are technical issues with this document.

Technically.
=E2=80=94 Carlos.

On May 25, 2017, at 10:26 AM, Gr= eg Mirsky <gr= egimirsky@gmail.com> wrote:

Dear Carlos,
thank you= for taking two minutes to write the message. From it all I've found on= ly one concern that, in my view, may be considered technical. Thus I'll= bring it to the forefront and will try to explain how the situation may be= handled.
You wrote:
1= . This approach assumes that FECs do not ever change. A reverse path is ins= tructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if pat= hs change?!? If a return tunnel is suddenly deleted from underneath?=
I consider it to be the cas= e that should be handled by properly operating the network rather then auto= -discovering it and auto-recovering. I hardly believe that a tunnel may be = "suddenly deleted" without the operator being aware of that. And = if that is the case, then the operator may proactively re-signal return pat= h for those BFD sessions that may be affected by the planned change in the = network. Even more, BFD sessions to decrease chance of receiving false nega= tive during period the remote BFD peer switches to new recommended path.

Thank you for the editorial suggestion to consi= der renaming the section. We'll discuss and share our proposal to impro= ve the wording.

Others may decide to respond = to the rest of your message. There's nothing of technical substance, as= I see it.

Regards,
Greg
=
On Wed, May 24, 2017 at 11:36 PM, Carlos Pig= nataro (cpignata) <cpignata@cisco.com> wrote:
Nic,

I do not support advancing this document in its current form. It has many t= echnical deficiencies, some of which are listed and described below.

I also believe your WGLC note should have been much more detailed and compr= ehensive.

I believe this is the 3rd WGLC on this document, correct? (That gives a new= meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also been cl= arified in the WGLC email, with a much more clear explanation and comprehen= sive set of details of how concerns were discussed and addressed.

> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.

I am very concerned that there was no discussion on the list of any = of those changes.=C2=A0 The authors believe the draft is ready =E2=80=94 do= you believe so as well, Nic? Was a shepherd review performed and is that a= vailable?

> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:

Is that the 1st or 2nd WGLC? I think this statement is an oversimpli= fication. There were many technical concerns.

Anyway, scanning through this document, some technical issues:

1. This approach assumes that FECs do not ever change. A reverse path is in= structed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if pa= ths change?!? If a return tunnel is suddenly deleted from underneath?
2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any other n= on-MPLS case? This points to the fact of lack of review and editorial slopp= iness.
3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D =E2=80=94 so basically, no Tunnels can be return path?!?
4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way that= does not make sense.

Please note, this is not an exhaustive list, but a 2 minute scan through th= e doc.

Thanks!

Carlos.


> On May 24, 2017, at 2:33 AM, n.leymann@telekom.de <N.Leymann@telekom.de> wrote:
>
> Dear Working Group,
>
> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
> Therefore this e-mail starts a WG LC which will end on the 7th of June= .
>
> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:
>
>=C2=A0 =C2=A0https://datatracker.ietf.org/ipr/2892/
>
> The authors have updated the draft and they believe that the IPR is no= longer in scope.
> Please notify the list if you still think the IPR is an issue and plea= se state if you think it
> is OK to continue with the publication of this document.
>
>=C2=A0 =C2=A0Best regards
>
>=C2=A0 =C2=A0 =C2=A0Nic
>
>
> ____________________________________________= ___
> mpls mailing list
> mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


--f403043c4bec20bb5b0550ca5fac--