Hi Greg, I would read it as " ... the liveness of a node over the specific interface ..." i.e, the node is reachable and responding over that interface.
Thanks, Ketan On Tue, Sep 26, 2023 at 7:16 PM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi, > as I understand it, the update assigns to the Unaffiliated BFD a new > functionality, monitoring "the liveness of a node not including the > availability of a specific IP address at that node". In my opinion, that > raises some questions: > > - What is "the liveness of a node"? > - When referring to the liveness of a node, does it applicable to > a single-box system or also to a virtual, distributed, e.g., the one using > the CUPS paradigm? > - How the liveness of a node is derived from the functionality of a > single interface? Is it equally applicable regardless the interface is > physical or virtual? > > Thank you for your consideration. > > Regards, > Greg > > On Tue, Sep 26, 2023 at 5:38 AM Ketan Talaulikar <ketant.i...@gmail.com> > wrote: > >> Thanks Xiao Min - the update looks good and addresses my comments. >> >> Thanks, >> Ketan >> >> On Tue, Sep 26, 2023 at 12:58 PM <xiao.m...@zte.com.cn> wrote: >> >>> Hi Ketan, >>> >>> >>> Thank you for the suggested text, very helpful. >>> >>> I've just posted a new revision that incorporates all your comments. >>> Link as below. >>> >>> >>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09> >>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09 >>> >>> >>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>Please >>> see inline with [XM-2]>>>. >>> Original >>> *From: *KetanTalaulikar <ketant.i...@gmail.com> >>> *To: *肖敏10093570; >>> *Cc: *draft-ietf-bfd-unaffiliated-e...@ietf.org < >>> draft-ietf-bfd-unaffiliated-e...@ietf.org>;rtg-bfd@ietf.org < >>> rtg-bfd@ietf.org>;jh...@pfrc.org <jh...@pfrc.org>; >>> *Date: *2023年09月25日 15:37 >>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08* >>> Hi Xiao Min, >>> Thanks for your response. Please check inline below for further >>> suggestions. >>> >>> On Mon, Sep 25, 2023 at 11:41 AM <xiao.m...@zte.com.cn> wrote: >>> >>>> Dear Ketan, >>>> >>>> >>>> Thanks for your review and thoughtful comments. >>>> Please see inline. >>>> Original >>>> *From: *KetanTalaulikar <ketant.i...@gmail.com> >>>> *To: *draft-ietf-bfd-unaffiliated-e...@ietf.org < >>>> draft-ietf-bfd-unaffiliated-e...@ietf.org>; >>>> *Cc: *rtg-bfd@ietf.org <rtg-bfd@ietf.org>;Jeffrey Haas <jh...@pfrc.org >>>> >; >>>> *Date: *2023年09月22日 22:55 >>>> *Subject: **Comments on draft-ietf-bfd-unaffiliated-echo-08* >>>> Hello Authors, >>>> >>>> Looks like I've missed the WGLC on this document, but nevertheless >>>> would like to share the following comments: >>>> >>>> Sec 1 of the document says: >>>> >>>> Section 5 of [RFC5880 >>>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5880> >>>> ] indicates that the payload of an affiliated BFD Echo packet is a >>>> local matter and hence its contents are outside the scope of that >>>> specification. This document, on the other hand, specifies the contents of >>>> the Unaffiliated BFD Echo packet and what to do with them. >>>> >>>> However, when I go through the procedures in Section 2, there is no >>>> description of the actual construction of the IP packet that A sends out to >>>> B - what is the source and destination IP - or MAC addresses for that >>>> matter? How is it that B would loop it back? I believe it is important for >>>> the document to specify this. >>>> >>>> [XM]>>> This document does specify the source and destination IP, >>>> through reference to RFC 5881. In section 2 it says >>>> >>>> "Regarding the selection of IP address, the rules stated in Section 4 >>>> of [RFC5881 <https://www.rfc-editor.org/info/rfc5881>] are applicable >>>> to the encapsulation of an Unaffiliated BFD Echo packet." >>>> >>>> In -07 version the rules of RFC 5881 were restated, however in -08 >>>> version they're removed by following the suggestion from Greg. >>>> >>> KT> I missed that conversation. One small suggestion so it covers not >>> just IP address but also MAC. >>> >>> OLD: Regarding the selection of IP address, the rules stated in Section >>> 4 of [RFC5881 >>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5881> >>> ] are applicable to the encapsulation of an Unaffiliated BFD Echo >>> packet. >>> >>> NEW: An Unaffiliated BFD Echo packet follows the same encapsulation >>> rules as for a BFD Echo packet as specified in Section 4 of [RFC5881 >>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5881> >>> ]. >>> >>> [XM-2]>>> Accepted. >>> >>> >>> >>>> Another important part is that normally BFD verifies the bidirectional >>>> path, the liveness of the other endpoint, but also validates the presence >>>> of a specific IP at that endpoint. Is that still the case when operating in >>>> this mode? This question arises since the document talks about liveness to >>>> servers - so is it monitoring liveness to the server host or a specific >>>> server IP? >>>> >>>> [XM]>>> It's monitoring liveness to the server host, not a specific >>>> server IP. Also note that the Unaffiliated BFD Echo can be used for >>>> multiple use cases, in section 1 it says >>>> >>>> "Section 6.2.2 of [BBF-TR-146 >>>> <https://www.broadband-forum.org/technical/download/TR-146.pdf>] describes >>>> one use case of the Unaffiliated BFD Echo. Section 2 of [ >>>> I-D.wang-bfd-one-arm-use-case >>>> <https://datatracker.ietf.org/doc/html/draft-wang-bfd-one-arm-use-case-00> >>>> ] describes another use case of the Unaffiliated BFD Echo." >>>> >>> KT> This is OK. I was looking for some text (perhaps in Section 1) that >>> says something on the lines of ... "The Unaffiliated BFD Echo functionality >>> only monitors liveness of the node and does not monitor the availability of >>> a specific IP address at that node." - I believe this is an important >>> distinction from normal BFD operations that needs to be called out. Would >>> you agree? >>> >>> [XM-2]>>> Some text as you want was added to section 1. >>> >>>> >>>> Finally, is it normal or natural to expect server hosts to be able to >>>> "loop them back by normal IP forwarding"? Or does it require some >>>> additional/special capabilities to be turned ON those hosts as hosts don't >>>> do forwarding by default. >>>> >>>> [XM]>>> As I know of a deployment, there is no need to turn ON those >>>> hosts. At the same time, it's feasible to have such a knob. Propose to add >>>> some text as below. >>>> >>>> OLD >>>> >>>> The method for provisioning device B to loop back BFD Unaffiliated Echo >>>> packets is outside the scope of this document. >>>> >>>> NEW >>>> >>>> There may be a knob to turn on/off the loopback of Unaffiliated BFD >>>> Echo packets at device B. The method for provisioning device B to loop >>>> back Unaffiliated BFD Echo packets is outside the scope of this >>>> document. >>>> >>>> >>>> KT> This is not quite where I was going. Perhaps something on the >>> following lines? >>> NEW: >>> BFD Unaffiliated Echo feature depends on device B performing IP >>> forwarding (actually IP redirect) functionality. While such functionality >>> may normally be expected to be supported on a router, it may not be enabled >>> on a host by default. The method for provisioning device B to loop back BFD >>> Unaffiliated Echo packets is outside the scope of this document. >>> >>> [XM-2]>>> Accepted. >>> >>> >>> Best Regards, >>> >>> Xiao Min >>> >>> >>> Thanks, >>> Ketan >>> >>> Best Regards, >>>> >>>> Xiao Min >>>> >>>> >>>> It would help if these aspects are clarified in the document. >>>> >>>> >>>> Thanks, >>>> Ketan >>>> >>>> On Thu, Jul 6, 2023 at 7:50 AM <internet-dra...@ietf.org> wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. This Internet-Draft is a work item of the Bidirectional >>>>> Forwarding Detection (BFD) WG of the IETF. >>>>> >>>>> Title : Unaffiliated BFD Echo >>>>> Authors : Weiqiang Cheng >>>>> Ruixue Wang >>>>> Xiao Min >>>>> Reshad Rahman >>>>> Raj Chetan Boddireddy >>>>> Filename : draft-ietf-bfd-unaffiliated-echo-08.txt >>>>> Pages : 12 >>>>> Date : 2023-07-05 >>>>> >>>>> Abstract: >>>>> Bidirectional Forwarding Detection (BFD) is a fault detection >>>>> protocol that can quickly determine a communication failure between >>>>> two forwarding engines. This document proposes a use of the BFD >>>>> Echo >>>>> where the local system supports BFD but the neighboring system does >>>>> not support BFD. BFD Control packet and its processing procedures >>>>> can be executed over the BFD Echo port where the neighboring system >>>>> only loops packets back to the local system. >>>>> >>>>> This document updates RFC 5880. >>>>> >>>>> The IETF datatracker status page for this Internet-Draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ >>>>> >>>>> There is also an htmlized version available at: >>>>> >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-08 >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-08 >>>>> >>>>> Internet-Drafts are also available by rsync at rsync.ietf.org: >>>>> :internet-drafts >>>>> >>>>> >>>>> >>>> >>>
