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".... <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." <snip> Thanks! Dhruv
