Hi Dhruv,
Thank you for the confirmation.
For the last two open items, please see inline.
OriginalFrom: DhruvDhody <dhruv.ietf@xxxxxxxxx>To: 肖敏10093570;Cc: dd@xxxxxxxxxxxxxx <dd@xxxxxxxxxxxxxx>;ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>;draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx <draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;rtg-bfd@xxxxxxxx <rtg-bfd@xxxxxxxx>;Date: 2024年10月10日 11:45Subject: [Last-Call] Re: Opsdir last call review of draft-ietf-bfd-unaffiliated-echo-11--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxxHi 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.
"Some devices that would benefit from the use of BFD may be unable toDhruv: 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 readssupport 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
