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