Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

[[e-mail]]

Hi Mahesh,

Thank you for the confirmation.
I'll change the text as we agreed.

Cheers,
Xiao Min


Original


From: MaheshJethanandani <[e-mail]>
To: 肖敏10093570;
Cc: Jeffrey Haas <[e-mail]>;The IESG <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;rtg-bfd@ietf. <[e-mail]>;
Date: 2024年10月17日 23:17
Subject: Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)


Hi Xiao,

Thanks for adding the references. This and the previous clarification update will address all my concerns. Cheers.
On Oct 17, 2024, at 12:23 AM, <[e-mail]> <[e-mail]> wrote:



Hi Jeff, Mahesh,

I'm following your discussion.
Please see inline.






Mahesh Jethanandani
[e-mail]

 





From: JeffreyHaas <[e-mail]>
To: Mahesh Jethanandani <[e-mail]>;
Cc: 肖敏10093570;The IESG <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;rtg-bfd@ietf. <[e-mail]>;
Date: 2024年10月17日 08:47
Subject: Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

Mahesh,


On Oct 16, 2024, at 7:23 PM, Mahesh Jethanandani <[e-mail]> wrote:



On Oct 16, 2024, at 12:15 PM, Jeffrey Haas <[e-mail]> wrote:


Mahesh,


On Oct 16, 2024, at 2:41 PM, Mahesh Jethanandani <[e-mail]> wrote:



[mj] I think I saw a similar comment on one of the other threads. It is not clear whether this “loopback” of packets is happening at layer 1 (physical) or layer 2 (IP layer). From the sound of it, it appears it is happening at layer 1, or at least where there is no lookup of IP address(es) happening. If there was, the destination address could be more than one hop away. In either case, clarifying how the packets are being “looped” back would help.



This draft is meant to be read with RFC 5880/5881 and should avoid trying to redefine things.

https://datatracker.ietf.org/doc/html/rfc5880#autoid-12
https://datatracker.ietf.org/doc/html/rfc5881#section-4







Please see the above to see if this clarifies your thinking.



It did, and thanks for the pointer. 

Rather than add the above suggested text, and if the idea is to not redefine things, how about adding the two links you suggest as a reference?


The authors certainly could add some additional text in the Introduction section clarifying that this feature extends the existing BFD Echo functionality with those references.
[XM]>>> OK. Propose to add those references as below.
OLD
When the Echo function is activated, the local system sends BFD Echo packets and the remote system loops back the received Echo packets through the forwarding path. If several consecutive BFD Echo packets are not received by the local system, then the BFD session is declared to be Down.
NEW
When the Echo function is activated, the local system sends BFD Echo packets and the remote system loops back the received Echo packets through the forwarding path, as described in Section 5 of [RFC5880] and Section 4 of [RFC5881]. If several consecutive BFD Echo packets are not received by the local system, then the BFD session is declared to be Down.
END

Cheers,
Xiao Min

-- Jeff




It specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop paths is that the Unaffiliated BFD Echo packets would be looped back by the first hop. A full description of the updates to [RFC5880] is provided in Section 3.