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 <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 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) <cpign...@cisco.com<mailto:cpign...@cisco.com>> 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, xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn> 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 <jh...@pfrc.org<mailto:jh...@pfrc.org>> 收件人：rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>; 日 期 ：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
