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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> wrote:
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
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**


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

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

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


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 <[e-mail]<mailto:[e-mail]>>
收件人：[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand
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