I would like to make a suggestion to the authors: OLD: Note that this method monitors the liveness of a node not including the availability of a specific IP address at that node.
NEW: Note that this method monitors the connectivity to a system over a specific interface and does not verify the availability of a specific IP address at that system. My originally suggested text was not using the terminologies from RFC5880. Greg, I hope this revised text addresses your concern? Thanks, Ketan On Thu, Sep 28, 2023 at 2:43 AM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Xiao Min, > thank you for your expedient response. Please find my notes below tagged > GIM>>. > > Regards, > Greg > > On Tue, Sep 26, 2023 at 6:37 PM <xiao.m...@zte.com.cn> wrote: > >> Hi Greg, >> >> >> Please see inline. >> Original >> *From: *GregMirsky <gregimir...@gmail.com> >> *To: *Ketan Talaulikar <ketant.i...@gmail.com>; >> *Cc: *肖敏10093570;rtg-bfd WG <rtg-bfd@ietf.org>; >> draft-ietf-bfd-unaffiliated-e...@ietf.org < >> draft-ietf-bfd-unaffiliated-e...@ietf.org>; >> *Date: *2023年09月27日 02:21 >> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08* >> Hi Ketan, >> Thank you for sharing your interpretation of the introduced text. I agree >> that your view is in line with how the scope of BFD is defined in RFC 5880: >> >> 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 >> >> But it is not clear to me how "liveness of a node" is retated to the >> definition above. I hope thr Authors will clarify that for me. >> [XM]>>> In my understanding it's the liveness of the forwarding engine. >> Do you expect s/the liveness of a node/the liveness of a node over the >> specific interface as Ketan clarified? >> >> GIM>> I think that the Unaffiliated BFD and BFD, in general, do not > detect defects on the nodal level. Thus, the "liveness of a node" seems > inaccurate, overstretching the scope of BFD as defined in RFC 5880. I > suggest referring to the definition of the BFD from RFC 5880 or providing > an explanation of how the Unaffiliated BFD extends the defect detection > domain up to the nodal scope. > > Regards, > Greg > >> >> Best Regards, >> Xiao Min >> >> >> Regards, >> >> Greg >> >> >> On Tue, Sep 26, 2023, 09:56 Ketan Talaulikar <ketant.i...@gmail.com> >> wrote: >> >>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>
