Subject: WG Adoption request for draft-mirsky-bfd-mpls-demand

From: Jeffrey Haas <[email-masked]>
Date: Wed, 17 Oct 2018 18:24:31 -0400

Working Group,

The BFD chairs have received an adoption request for 
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).

https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:
https://datatracker.ietf.org/ipr/3301/
https://datatracker.ietf.org/ipr/3104/

Please indicate to the mailing list whether you support adoption of this
draft.

-- Jeff & Reshad

---

From: <[email-masked]>
Date: Sat, 20 Oct 2018 09:59:39 +0800 (CST)

I support WG adoption of this draft. Use of the demand mode for p2p LSP monitoring is feasible and required.

Best Regards,

Xiao Min

原始邮件

发件人：JeffreyHaas <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand

Working Group,

-- Jeff & Reshad

---

From: <[email-masked]>
Date: Sun, 21 Oct 2018 09:41:50 +0800 (CST)

Hi, all

I support the adoption. 

Regards

Fangwei.

Working Group,

-- Jeff & Reshad

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Oct 2018 04:04:18 +0000

Xiao,

Scanning through the draft, two questions:

1. What is the underlying mechanism to check liveness such that Demand can be used?

https://tools.ietf.org/html/rfc5880#section-6.6

   Demand mode requires that some other mechanism is used to imply
   continuing connectivity between the two systems.  The mechanism used

2. Is this draft testing liveness of a path or a node?

https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3

   In this state BFD peers MAY remain as long as the egress LER is in Up
   state.  The ingress LER MAY check liveness of the egress LER by
   setting the Poll flag.  The egress LER will respond by transmitting

Thanks,

— Carlos Pignataro

On Oct 19, 2018, at 9:59 PM, [email-masked]<mailto:[email-masked]> wrote:

Best Regards,

Xiao Min

原始邮件
发件人：JeffreyHaas <[email-masked]<mailto:[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand
Working Group,

-- Jeff & Reshad

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Oct 2018 08:23:51 -0700

Hi Carlos,
thank you for your interest in the draft and the questions. Please find my
answers in-line tagged GIM>>.

Regards,
Greg

On Thu, Oct 25, 2018 at 9:04 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> GIM>> The Poll sequence may also be used as such, and
> draft-ietf-bfd-multipoint-active-tail is the example of how the Poll
> sequence is used in BFD Demand mode.
>
> GIM>> BFD does not differentiate between the path and, to certain extent,
> the node. From RFC 5880 Abstract:
>
   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.

>
> Thanks,
>
> — Carlos Pignataro
>
> On Oct 19, 2018, at 9:59 PM, [email-masked] wrote:
>
> *发件人：*JeffreyHaas <[email-masked]>
> *收件人：[email-masked] <[email-masked]>;
> *日 期 ：*2018年10月18日 06:24
> *主 题 ：**WG Adoption request for draft-mirsky-bfd-mpls-demand*
> Working Group,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Oct 2018 21:28:18 +0000

Hi, Greg,

Thanks for the quick response — please see inline, since I do not believe you were answering my actual points.

On Oct 26, 2018, at 11:23 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
thank you for your interest in the draft and the questions. Please find my answers in-line tagged GIM>>.

Regards,
Greg

On Thu, Oct 25, 2018 at 9:04 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Xiao,

   Demand mode requires that some other mechanism is used to imply
   continuing connectivity between the two systems.  The mechanism used
GIM>> The Poll sequence may also be used as such, and draft-ietf-bfd-multipoint-active-tail is the example of how the Poll sequence is used in BFD Demand mode.

This is not what the spec says. Quoting the same text again, but adding emphasis:

   Demand mode **requires** that **some other mechanism** is used to imply
   continuing connectivity between the two systems.  The mechanism used

What is the **some other mechanism** outside BFD, in this case? It is something that Demand mode **requires**

GIM>> BFD does not differentiate between the path and, to certain extent, the node. From RFC 5880 Abstract:

The text you quote says nothing about the node. Only about the *path* and *forwarding* elements...

What is, for BFD, to "check liveness of the egress LER”?

Best,

Carlos.

Thanks,

— Carlos Pignataro

Best Regards,

Xiao Min

原始邮件

-- Jeff & Reshad

---

From: <[email-masked]>
Date: Sat, 27 Oct 2018 13:07:41 +0800 (CST)

Hi Carlos,

My answers to your two questions are as follow:

In section 6.6 of RFC5880, just after the text you quoted, it says "One possible mechanism is the receipt of traffic from the remote system; another is the use of the Echo function." So I'm not sure what's your real concern.

In the abstract of this draft it says "This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths." If you don't like the expression form of the text quoted by you, pls feel free to propose some text.

Best Regards,

Xiao Min

原始邮件

发件人：CarlosPignataro(cpignata) <[email-masked]>
收件人：肖敏10093570;
抄送人：Jeff Haas <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2018年10月26日 12:04
主 题 ：Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

Xiao, 

 

 

Thanks,
 
— Carlos Pignataro

 

Best Regards,

Xiao Min

 

日 期 ：2018年10月18日 06:24

Working Group, The BFD chairs have received an adoption request for  "BFD in Demand Mode over Point-to-Point MPLS LSP" (draft-mirsky-bfd-mpls-demand). https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/ The adoption call will end on the Friday after IETF 103, November 9. Note that there is are existing IPR statements on this draft: https://datatracker.ietf.org/ipr/3301/ https://datatracker.ietf.org/ipr/3104/ Please indicate to the mailing list whether you support adoption of this draft. -- Jeff & Reshad

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 27 Oct 2018 15:44:57 +0000

Hi Xiao,

Thanks much for the quick response!

Please find my follow ups:

1. Sorry if I was not clear. Yes, RFC 5880 lists exemplary possible mechanisms to glean continued connectivity but requires the use of one. My question is: which mechanisms does this draft propose? Could it please be spelled out?

2. Again, apologies if I was not clean enough. I understand what the abstract says, but the quoted text says that live was needs to be checked for a node (egress LER) instead of the forwarding path. Does that mean ~ “of the forwarding path towards/upto the node”?

Thanks for your consideration.

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 27, 2018, at 01:07, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

  1.  In section 6.6 of RFC5880, just after the text you quoted, it says "One possible mechanism is the receipt of traffic from the remote system; another is the use of the Echo function." So I'm not sure what's your real concern.

  2.  In the abstract of this draft it says "This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths." If you don't like the expression form of the text quoted by you, pls feel free to propose some text.

Best Regards,

Xiao Min

原始邮件
发件人：CarlosPignataro(cpignata) <[email-masked]<mailto:[email-masked]>>
收件人：肖敏10093570;
抄送人：Jeff Haas <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2018年10月26日 12:04
主 题 ：Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
Xiao,
Scanning through the draft, two questions:

Thanks,

— Carlos Pignataro

Best Regards,

Xiao Min

-- Jeff & Reshad

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 27 Oct 2018 12:14:35 -0700

Hi Carlos,
thank you for the continued discussion. Please find my answers in-line
tagged GIM>>.

Regards,
Greg

On Sat, Oct 27, 2018 at 8:45 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> 1. Sorry if I was not clear. Yes, RFC 5880 lists exemplary possible
> mechanisms to glean continued connectivity but requires the use of one. My
> question is: which mechanisms does this draft propose? Could it please be
> spelled out?
>
GIM>> I have to point that:

   - BFD for Multipoint Networks uses the Demand mode of BFD with no such
   mechanism;
   - BFD for Multipoint Networks with Active Tail uses Poll sequence
   (possibly combination of multicast Poll and unicast Poll) to verify
   availability of the multicast path. But according to your interpretation of
   RFC 5880, this is not one of mechanisms to be used.

Now I have a question to you Do you believe that these two BFD
specifications for multicast and multipoint networks are insufifcient or
impaired because of the way the Demand mode being used?

>
> 2. Again, apologies if I was not clean enough. I understand what the
> abstract says, but the quoted text says that live was needs to be checked
> for a node (egress LER) instead of the forwarding path. Does that mean ~
> “of the forwarding path towards/upto the node”?
>
GIM>> Thank you for pointing to this issue. In the next version will
clarify that the Poll sequence allows the ingress LER to verify
availability of the LSP and the liveness of the egress LER.

> On Oct 27, 2018, at 01:07, "[email-masked]" <[email-masked]>
> wrote:
>
> Hi Carlos,
>
>
>    1.
>    In section 6.6 of RFC5880, just after the text you quoted, it says
>    "One possible mechanism is the receipt of traffic from the remote system;
>    another is the use of the Echo function." So I'm not sure what's your real
>    concern.
>    2.
>
>    In the abstract of this draft it says "This document describes
>    procedures for using Bidirectional Forwarding Detection (BFD) in Demand
>    mode to detect data plane failures in Multiprotocol Label Switching (MPLS)
>    point-to-point Label Switched Paths." If you don't like the expression form
>    of the text quoted by you, pls feel free to propose some text.
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人：*CarlosPignataro(cpignata) <[email-masked]>
> *收件人：*肖敏10093570;
> *抄送人：*Jeff Haas <[email-masked]>;[email-masked] <[email-masked]>;
> *日 期 ：*2018年10月26日 12:04
> *主 题 ：**Re: WG Adoption request for draft-mirsky-bfd-mpls-demand*
> Xiao,