Re: Comments on draft-ietf-bfd-unaffiliated-echo-08

[Ketan Talaulikar <[e-mail]>]

Thanks Xiao Min - the update looks good and addresses my comments.

Thanks,
Ketan

On Tue, Sep 26, 2023 at 12:58 PM <[e-mail]> 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 <[e-mail]>
> *To: *肖敏10093570;
> *Cc: *[e-mail] <
> [e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> *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 <[e-mail]> wrote:
>
>> Dear Ketan,
>>
>>
>> Thanks for your review and thoughtful comments.
>> Please see inline.
>> Original
>> *From: *KetanTalaulikar <[e-mail]>
>> *To: *[e-mail] <
>> [e-mail]>;
>> *Cc: *[e-mail] <[e-mail]>;Jeffrey Haas <[e-mail]>;
>> *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 <[e-mail]> 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
>>>
>>>
>>>
>>
>