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