Subject: [spring] The SPRING WG has placed draft-mirsky-spring-bfd in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Tue, 08 Sep 2020 11:08:31 -0700

The SPRING WG has placed draft-mirsky-spring-bfd in state
Call For Adoption By WG Issued (entered by Joel Halpern)

The document is available at
https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/

Comment:
The authors have requested (quite some time ago) WG adoption for this
document.  Looking at the archive, there was anot a lot of discussion, and
some concerns.  Rather than try to infer the current state from the old
discussions, the WG Chairs have decided to issue a WG call for adoption.  If
you support this becoming a WG document, please explain on the list.  If you
oppose this becoming a WG document, please explain on the list.  Silence does
not mean consent.

Yours,
Joel M. Halpern

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 Sep 2020 14:17:35 -0700

Dear All,
I support the adoption of draft-mirsky-spring-bfd by the SPRING WG for the
following reasons:

   - optional control of the reverse path of the BFD session in SR-MPLS
   environment;
   - optional reduction of OAM data exchanged between BFD systems by using
   the BFD in Demand mode over an SR-MPLS tunnel;
   - ability to monitor p2mp SR policies.

I want to highlight the third point. BFD (based on RFC 5880) has solutions
for lightweight mechanisms to detect defects in a p2mp tunnel. The solution
defined in RFC 8562 allows egress BFD nodes to monitor the state of the
head-end and related part of the multicast distribution tree. In some
scenarios, it is desirable for the head-end to be able to know the state of
an egress node and egress's view of the distribution tree. Three options
listed in RFC 8563:

   - head notifications with multicast polling
   - head notifications with composite polling
   - unsolicited notifications

The two first options described in RFC 8563 in detail while the third is
very sketchy. This is the option discussed in the draft, pointing to the
solution defined in draft-mirsky-mpls-p2mp-bfd.

Always welcome your questions.

Regards,
Greg

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 14 Sep 2020 15:24:09 -0700

I support the adoption as co-author, for the reasons outlined by Greg.

Cheers,
Jeff
On Sep 14, 2020, 2:17 PM -0700, Greg Mirsky <[email-masked]>, wrote:
> Dear All,
> I support the adoption of draft-mirsky-spring-bfd by the SPRING WG for the following reasons:
>
> • optional control of the reverse path of the BFD session in SR-MPLS environment;
> • optional reduction of OAM data exchanged between BFD systems by using the BFD in Demand mode over an SR-MPLS tunnel;
> • ability to monitor p2mp SR policies.
>
> I want to highlight the third point. BFD (based on RFC 5880) has solutions for lightweight mechanisms to detect defects in a p2mp tunnel. The solution defined in RFC 8562 allows egress BFD nodes to monitor the state of the head-end and related part of the multicast distribution tree. In some scenarios, it is desirable for the head-end to be able to know the state of an egress node and egress's view of the distribution tree. Three options listed in RFC 8563:
>
> • head notifications with multicast polling
> • head notifications with composite polling
> • unsolicited notifications
>
> The two first options described in RFC 8563 in detail while the third is very sketchy. This is the option discussed in the draft, pointing to the solution defined in draft-mirsky-mpls-p2mp-bfd.
>
> > On Tue, Sep 8, 2020 at 11:08 AM IETF Secretariat <[email-masked]> wrote:
> > >

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Sep 2020 19:11:05 -0400

I support WG adoption of this well written draft for the reasons outlined
by Greg.

I wanted to note an orthogonal caveat  related to this draft for monitoring
of SR-MPLS P2MP P-Tree.

RFC 8562 and RFC 8563 relates to mLDP PTA P-Tree, however in a pure SR-MPLS
environment where LDP has been eliminated that  P2MP trees would have to be
provided via some other mechanism,  IR, replication SID or BIER.

However there are some use cases where operators end up keeping LDP present
for mLDP extension use for PMSI P-Tree instantiation for “multicast” only
and use SR-MPLS for “unicast”.  In this case the P2MP P-Tree over MPLS is
relevant to the draft.

Thank you

Gyan

On Mon, Sep 14, 2020 at 6:24 PM Jeff Tantsura <[email-masked]>
wrote:

>    - optional reduction of OAM data exchanged between BFD systems by
>    using the BFD in Demand mode over an SR-MPLS tunnel;
>
> _______________________________________________
>
> spring mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/spring
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: <[email-masked]>
Date: Tue, 15 Sep 2020 14:02:19 +0800 (CST)

I support WG adoption this draft since it enables the use of BFD Demand mode that reduces amount of BFD control messages received by the ingress BFD system.

Regards,

Aihua

原始邮件

发件人：GregMirsky <[email-masked]>
收件人：IETF Secretariat <[email-masked]>;
抄送人：spring <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年09月15日 05:18
主 题 ：Re: [spring] The SPRING WG has placed draft-mirsky-spring-bfd instate "Call For Adoption By WG Issued"

Dear All,I support the adoption of draft-mirsky-spring-bfd by the SPRING WG for the following reasons:
optional control of the reverse path of the BFD session in SR-MPLS environment;

optional reduction of OAM data exchanged between BFD systems by using the BFD in Demand mode over an SR-MPLS tunnel;

ability to monitor p2mp SR policies.

I want to highlight the third point. BFD (based on RFC 5880) has solutions for lightweight mechanisms to detect defects in a p2mp tunnel. The solution defined in RFC 8562 allows egress BFD nodes to monitor the state of the head-end and related part of the multicast distribution tree. In some scenarios, it is desirable for the head-end to be able to know the state of an egress node and egress's view of the distribution tree. Three options listed in RFC 8563:
head notifications with multicast polling

head notifications with composite polling

unsolicited notifications

Regards,
Greg

Comment:

Yours,
Joel M. Halpern

---

From: <[email-masked]>
Date: Tue, 15 Sep 2020 20:42:08 +0800 (CST)

Hi WG,

I support the adoption of this draft.

The extensions based on LSP ping is clear. And it enables the control of the reverse path, which can reduce the number of BFD sessions and amount of state information in BFD system.

Regards,

Yao

原始邮件

Regards,
Greg

Comment:

Yours,
Joel M. Halpern

---

From: <[email-masked]>
Date: Thu, 17 Sep 2020 15:31:29 +0800 (CST)

Hi,

I support the adoption.

This document enables a more flexible control of the reverse path for the BFD in SR-MPLS network,  provides the solution to the problems that we are faced in the actual network deployment.

Regards,

PSF

原始邮件

发件人：IETFSecretariat <[email-masked]>
收件人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年09月09日 02:08
主 题 ：[spring] The SPRING WG has placed draft-mirsky-spring-bfd in state"Call For Adoption By WG Issued"

Comment:

Yours,
Joel M. Halpern

---

From: 姜文颖 <[email-masked]>
Date: Fri, 18 Sep 2020 14:44:11 +0800 (CST)

Hi,

I support the adoption.

This document provides a good method  of the reverse path control for the BFD in SR-MPLS network, which is very helpful for the deployment of SR-TE technology in the carrier network

Regards,

Wenying

祝好！

******************************************************

姜文颖

中国移动通信研究院 网络技术研究所

地址：北京市西城区宣武门西大街32号（100053）

Email：[email-masked]

电话：15801696688-34257，13810389325

******************************************************

----邮件原文----发件人："peng.shaofu" <[email-masked]>收件人：ietf-secretariat-reply <[email-masked]>抄　送: spring <[email-masked]>,spring-chairs <[email-masked]>,draft-mirsky-spring-bfd <[email-masked]>发送时间：2020-09-17 15:31:29主题：Re:[spring] The SPRING WG has placed draft-mirsky-spring-bfd in state"Call For Adoption By WG Issued"

Hi,

I support the adoption.

Regards,

PSF

原始邮件

发件人：IETFSecretariat <[email-masked]>
收件人：[email-masked] <[email-masked]>[email-masked] <[email-masked]>[email-masked] <[email-masked]>
日 期 ：2020年09月09日 02:08
主 题 ：[spring] The SPRING WG has placed draft-mirsky-spring-bfd in state"Call For Adoption By WG Issued"

The SPRING WG has placed draft-mirsky-spring-bfd in stateCall For Adoption By WG Issued (entered by Joel Halpern)The document is available athttps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/Comment:The authors have requested (quite some time ago) WG adoption for thisdocument.  Looking at the archive, there was anot a lot of discussion, andsome concerns.  Rather than try to infer the current state from the olddiscussions, the WG Chairs have decided to issue a WG call for adoption.  Ifyou support this becoming a WG document, please explain on the list.  If youoppose this becoming a WG document, please explain on the list.  Silence doesnot mean consent.Yours,Joel M. Halpern_______________________________________________spring mailing [email-masked]://www.ietf.org/mailman/listinfo/spring

---

From: 姜文颖 <[email-masked]>
Date: Fri, 18 Sep 2020 14:23:17 +0800 (CST)

Hi,

I support the adoption.

Regards,

Wenying

姜文颖

中国移动通信研究院 网络技术研究所

 

原始邮件

---

From: ILya Varlashkin <[email-masked]>
Date: Sun, 20 Sep 2020 17:52:28 +0100

I also support the adoption as co-author for the same reasons as outlines by Greg.

Kind regards,
iLya Varlashkin

> On 14 Sep 2020, at 23:24, Jeff Tantsura <[email-masked]> wrote:
> 
>

---

From: <[email-masked]>
Date: Mon, 21 Sep 2020 17:34:27 +0800 (CST)

Support the adoption. IMO the question described by this draft is interesting and needs to be solved.

Thanks,

Sandy

原始邮件

Comment:

Yours,
Joel M. Halpern