Thanks Xiao for handling my comments! On Thu, Oct 10, 2024 at 12:01 PM <[email protected]> wrote:
> Hi Dhruv, > > > Thank you for the confirmation. > > For the last two open items, please see inline. > Original > *From: *DhruvDhody <[email protected]> > *To: *肖敏10093570; > *Cc: *[email protected] <[email protected]>;[email protected] < > [email protected]>;[email protected] < > [email protected]>;[email protected] < > [email protected]>;[email protected] <[email protected]>; > *Date: *2024年10月10日 11:45 > *Subject: **[Last-Call] Re: Opsdir last call review of > draft-ietf-bfd-unaffiliated-echo-11* > -- > last-call mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Hi Xiao, > > I am happy with your resolutions! Snipping to... > > >>> >>> >>> The document does not include an explicit manageability & operational >>> >>> considerations section. Authors could consider adding it. RFC 5880 has it >>> and >>> it would make sense to call out considerations that are specific to >>> >>> Unaffiliated BFD Echo (if any). For instance - Does BFD enabled system A >>> know >>> >>> that the BFD Echo session is unaffiliated? Is there a configuration? How >>> does >>> it work with affiliated BFD Echo sessions? >>> >>> [XM]>>> OK. Propose to add a new section 4 as below. >>> >>> NEW >>> >>> 4. Operational Considerations >>> >>> >>> All Operational Considerations from [RFC5880] apply, except that >>> >>> the Unaffiliated BFD Echo can only be used across one hop, which >>> >>> result in unneccessity of a congestion control mechanism. >>> >>> >>> Some devices that would benefit from the use of BFD may be unable to >>> >>> support the full BFD protocol. Examples of such devices include >>> >>> servers running virtual machines, or Internet of Things (IoT) >>> >>> devices. >>> >>> >>> As specified in Section 2 of this document, some configurations are >>> >>> needed to make the Unaffiliated BFD Echo work, although the >>> >>> configurations won't be beyond the scope of [RFC5880]. >>> >>> At a BFD-enabled local system, the Unaffiliated BFD Echo session >>> >>> can coexist with other BFD session, in which scenario the remote >>> >>> systems and the local discriminators must be different, at the same >>> >> Dhruv: I am not able to parse this sentence. Do you mean that the ""My >> Discriminator" used by the local systems for unaffiliated BFD echo session >> should be different from affiliated ones? >> >> [XM]>>> Yes. Exactly there is no affiliated BFD Echo session, because in >> RFC 5880 the Echo function is an adjunct to Asynchronous mode or Demand >> mode. For the relationship between the local discriminator and the "My >> Discriminator" field in the BFD Control packet, please refer to Section 6.3 >> of RFC 5880, it says >> >> " >> >> Each system MUST choose an opaque discriminator value that identifies >> each session, and which MUST be unique among all BFD sessions on the >> system. The local discriminator is sent in the My Discriminator field in >> the BFD Control packet, and is echoed back in the Your Discriminator >> field of packets sent from the remote end. >> >> " >> > > Dhruv2: I understand that, but I still can't parse "the remote systems and > the local discriminators", perhaps this should be - "the remote system's > and the local system's discriminators must be different" or "the remote and > the local system's discriminators must be different".... > > [XM]>>> I see the confusion in my proposed text. Propose to rephrase the > related text as below. > > OLD > > At a BFD-enabled local system, the Unaffiliated BFD Echo session > > can coexist with other BFD session, in which scenario the remote > > systems and the local discriminators must be different, ... > > NEW > > At a BFD-enabled local system, the Unaffiliated BFD Echo session > > can coexist with other BFD session, in which scenario the remote > > system for the Unaffiliated BFD Echo session must be different from the > remote system for the other BFD session, and the local system's > discriminators for different BFD sessions must be different, ... > > END > > > <snip> > >> >> >>> >>> >>> - It would make sense to have the use case described in this document itself >>> >>> with suitable references. Reading section 6.2.2 of [BBF-TR-146] does not >>> help >>> in having a clear description of why an Unaffiliated BFD Echo is needed. >>> >>> [XM]>>> The original section 4 "Unaffiliated BFD Echo Applicability" was >>> removed in version -11 as per suggestion from Eric Vyncke. In order to >>> address your comments, I suggest to add some text from the original section >>> 4 to the new added section 4 "Operational Considerations" as above. >>> >>> >>> >> Dhruv: Yes, just a sentence or two on usecase would be fine. >> [XM]>>> To make the usecase more explicit to the reader, I'll add one >> more sentence to the second paragraph of "Operational Considerations", now >> it reads >> "Some devices that would benefit from the use of BFD may be unable to >> >> support the full BFD protocol. Examples of such devices include >> >> servers running virtual machines, or Internet of Things (IoT) >> >> devices. By using the Unaffiliated BFD Echo, what such devices need to >> support is only a simple loop-back function." >> >> Is that ok for you? >> > > Dhruv2: How about "By using Unaffiliated BFD Echo, these devices only need > to support a basic loopback function." > > [XM]>>> Yes, will use your text in the next revision. > > > Cheers, > > Xiao Min > > > <snip> > > Thanks! > Dhruv > > >
