Subject: Several questions about the draft-ietf-bfd-unaffiliated-echo

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Nov 2021 09:39:36 -0800

Dear Authors,
I've read the latest version and I have several questions. I greatly
appreciate your insights and clarifications:

   - Firstly, what is being standardized by this specification? I couldn't
   find that the described process requires any cooperation, action from a
   remote BFD peer. As I can see, only the sender of BFD Echo packets is
   acting and thus every action, e.g., construction of the test probe, a
   method to demultiplex incoming test packets, etc., is internal to the
   sender. Hence, it appears that there is nothing to be standardized as
   all of it is internal processing that does not impact any other BFD system.
   - The first update to RFC 5880 seems to suggest that the Echo function
   is an essential part of both Asynchronous and Demand modes of BFD. The
   original text of RFC 5880 characterizes the Echo function as an adjunct,
   i.e., a supplemental, function. The proposed new text - as a function that
   completes both BFD modes, makes them perfect, i.e., is an essential,
   necessary component. I think that that is not really the case and the BFD
   Echo function is not an essential, optional function of the BFD protocol.
   - The last sentence in the next proposed update to the RFC 5880 concerns
   me:

The Echo function may also be used independently, with neither Asynchronous
nor Demand mode.

It appears that, if accepted, the BFD Echo function is transformed into an
additional BFD mode. If that is the case, then this specification, in my
opinion, is not updating the RFC 5880 but is defining a new protocol.

   - For all the proposed updates to the RFC 5880, it is not clear why
   in some proposed texts, both modes, Asynchronous, and Demand, are
   referenced but in some only the Asynchronous. For example, updates to
   Section 6.1, Section 6.4, and Section 6.8.3 refer only to the Asynchronous
   mode, while updates to Section 6.8 and Section 6.8.9 - refer to both BFD
   modes.
   - In the second paragraph of Section 3 of the draft, the specification
   recommends that an implementation supporting this draft follows the BFD
   state machine, as defined in RFC 5880. Why is it a recommendation and not a
   requirement? And further, if an implementation does not follow the BFD
   state machine, is it still BFD?
   - Further, in the third paragraph of Section 3, it appears that the BFD
   Echo function on device A starts transmitting BFD control packets once the
   session is created. What is the state of the created BFD Echo session? As I
   understand it, the BFD state machine starts from the Init. Isn't that the
   case for this document as well?
   - In the same first sentence of the third paragraph in Section 3,
   another recommendation reads as "SHOULD include a BFD Echo session
   demultiplexing field". I have questions similar to the recommendation in
   the second paragraph of Section 3:
      - Why is it a recommendation and not a requirement?
      - What happens if an implementation does not include that particular
      field in the transmitted packets? Is it still a BFD Echo? How
then sessions
      are demultiplexed?

I greatly appreciate your consideration and help in clarifying these
aspects of the draft.

Now, I may have an alternative proposal that can produce the desired result
and not require any update to RFC 5880. Please consider the following:

   - RFC 8562 introduced a new type of the BFD session - MultipointHead. A
   system acting as the MultipointHead periodically transmits BFD Control
   packets in Demand mode, doesn't have the Init state, and starts in the Up
   state (no three-way handshake).
   - Considering the above, a system that uses the Unaffiliated BFD Echo
   starts as MultipointHead with bfd.DesiredMinTxInterval set to the maximum
   value (or any sanely large enough). The exact construction of the periodic
   BFD Control packets transmitted by the MultipointHead needs some detailed
   analysis (I haven't spent enough time on that).
   - In the meantime, because the BFD session for the MultipointHead
   started in the Up state, it can transmit BFD Echo packets according to RFC
   5880 and RFC 8562.

I think that if this proposal works, it may be moved as Informational since
it describes the use of well-known BFD principles and mechanisms in an
innovative and useful manner.
What are your thoughts, questions?

Regards,
Greg

---

From: <[email-masked]>
Date: Wed, 17 Nov 2021 17:00:09 +0800 (CST)

Hi Greg,

Thanks for your thorough review and insightful questions.
I hold the pen for draft-ietf-bfd-unaffiliated-echo, so I'd like to give my reply first.
As you may have known or not, before this draft was posted, we ever tried to submit an errata instead of an I-D. However, under the direction of the responsible AD and WG chairs, we realized that an informational draft might be the proper way to record our implementation and deployment. And then, during the adoption poll of this draft, there was rough consensus that this draft should be adopted as standards track document, so we changed the intended status from informational to standards track.
Please see inline for more responses with XM>>>.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：GregMirsky
收件人：[email-masked];rtg-bfd WG;
日 期 ：2021年11月17日 01:40
主 题 ：Several questions about the draft-ietf-bfd-unaffiliated-echo
Dear Authors,I've read the latest version and I have several questions. I greatly appreciate your insights and clarifications:
Firstly, what is being standardized by this specification? I couldn't find that the described process requires any cooperation, action from a remote BFD peer. As I can see, only the sender of BFD Echo packets is acting and thus every action, e.g., construction of the test probe, a method to demultiplex incoming test packets, etc., is internal to the sender. Hence, it appears that there is nothing to be standardized as all of it is internal processing that does not impact any other BFD system.
XM>>> The intention is to record a popular use of the BFD Echo function that doesn't comply with RFC 5880, at the same time this document does some clean-ups to RFC 5880.

The first update to RFC 5880 seems to suggest that the Echo function is an essential part of both Asynchronous and Demand modes of BFD. The original text of RFC 5880 characterizes the Echo function as an adjunct, i.e., a supplemental, function. The proposed new text - as a function that completes both BFD modes, makes them perfect, i.e., is an essential, necessary component. I think that that is not really the case and the BFD Echo function is not an essential, optional function of the BFD protocol.
XM>>> Does s/complement/supplement work for you?

The last sentence in the next proposed update to the RFC 5880 concerns me:
The Echo function may also be used independently, with neither Asynchronous nor Demand mode.
It appears that, if accepted, the BFD Echo function is transformed into an additional BFD mode. If that is the case, then this specification, in my opinion, is not updating the RFC 5880 but is defining a new protocol.
XM>>> I tend to agree that the Unaffiliated BFD Echo can be seen as a new BFD mode, however I don't think it's defining a new protocol, it's definitely based on BFD protocol.

For all the proposed updates to the RFC 5880, it is not clear why in some proposed texts, both modes, Asynchronous, and Demand, are referenced but in some only the Asynchronous. For example, updates to Section 6.1, Section 6.4, and Section 6.8.3 refer only to the Asynchronous mode, while updates to Section 6.8 and Section 6.8.9 - refer to both BFD modes.
XM>>> As I recall it, the reason is that some updated text applies to Asynchronous mode only, and some others applies to both modes.

In the second paragraph of Section 3 of the draft, the specification recommends that an implementation supporting this draft follows the BFD state machine, as defined in RFC 5880. Why is it a recommendation and not a requirement? And further, if an implementation does not follow the BFD state machine, is it still BFD?
XM>>> Make sense. I think we can make it a requirement instead of recommendation.

Further, in the third paragraph of Section 3, it appears that the BFD Echo function on device A starts transmitting BFD control packets once the session is created. What is the state of the created BFD Echo session? As I understand it, the BFD state machine starts from the Init. Isn't that the case for this document as well?
XM>>> No change to the BFD state machine. As I understand it, it's DOWN state.

In the same first sentence of the third paragraph in Section 3, another recommendation reads as "SHOULD include a BFD Echo session demultiplexing field". I have questions similar to the recommendation in the second paragraph of Section 3:
Why is it a recommendation and not a requirement?
What happens if an implementation does not include that particular field in the transmitted packets? Is it still a BFD Echo? How then sessions are demultiplexed?
I greatly appreciate your consideration and help in clarifying these aspects of the draft.
XM>>> Is that possible an implementation uses IP five tuples to demultiplex the loopbacked packets? If not, I agree to change from SHOULD to MUST.

Now, I may have an alternative proposal that can produce the desired result and not require any update to RFC 5880. Please consider the following:
RFC 8562 introduced a new type of the BFD session - MultipointHead. A system acting as the MultipointHead periodically transmits BFD Control packets in Demand mode, doesn't have the Init state, and starts in the Up state (no three-way handshake).
Considering the above, a system that uses the Unaffiliated BFD Echo starts as MultipointHead with bfd.DesiredMinTxInterval set to the maximum value (or any sanely large enough). The exact construction of the periodic BFD Control packets transmitted by the MultipointHead needs some detailed analysis (I haven't spent enough time on that).
In the meantime, because the BFD session for the MultipointHead started in the Up state, it can transmit BFD Echo packets according to RFC 5880 and RFC 8562.
I think that if this proposal works, it may be moved as Informational since it describes the use of well-known BFD principles and mechanisms in an innovative and useful manner.
XM>>> Although I'm unfamiliar with RFC 8562, while seeing BFD Demand mode, the first question came to my mind is that, can the peer system of MultipointHead be a BFD-unware device? That's the key requirement which results in Unaffiliated BFD Echo.
Thank you again, Greg.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Nov 2021 07:48:34 -0800

Hi Xiao Min,
thank you for your quick response to my questions and comments. Please find
my follow-up notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Nov 17, 2021 at 1:00 AM <[email-masked]> wrote:

> As you may have known or not, before this draft was posted, we ever tried
> to submit an errata instead of an I-D. However, under the direction of the
> responsible AD and WG chairs, we realized that an informational draft might
> be the proper way to record our implementation and deployment. And then,
> during the adoption poll of this draft, there was rough consensus that this
> draft should be adopted as standards track document, so we changed the
> intended status from informational to standards track.
> Dear Authors,I've read the latest version and I have several questions. I
> greatly appreciate your insights and clarifications:
> Firstly, what is being standardized by this specification? I couldn't find
> that the described process requires any cooperation, action from a remote
> BFD peer. As I can see, only the sender of BFD Echo packets is acting and
> thus every action, e.g., construction of the test probe, a method to
> demultiplex incoming test packets, etc., is internal to the sender. Hence,
> it appears that there is nothing to be standardized as all of it is
> internal processing that does not impact any other BFD system.
> XM>>> The intention is to record a popular use of the BFD Echo function
> that doesn't comply with RFC 5880, at the same time this document does some
> clean-ups to RFC 5880.
>
GIM>> In my opinion, if something doesn't comply with the protocol, then it
must be re-worked, not the protocol. If that is not possible, then,
probably, that is not really a part of the protocol.

>
> The first update to RFC 5880 seems to suggest that the Echo function is an
> essential part of both Asynchronous and Demand modes of BFD. The original
> text of RFC 5880 characterizes the Echo function as an adjunct, i.e., a
> supplemental, function. The proposed new text - as a function that
GIM>> That is better but "adjunct" has the same meaning as "complement". I
propose removing "complement" altogether and, as the result, leaving the
text in RFC 5880 unchanged.

> XM>>> I tend to agree that the Unaffiliated BFD Echo can be seen as a new
> BFD mode, however I don't think it's defining a new protocol, it's
> definitely based on BFD protocol.
>
GIM>> If the BFD Echo is a new BFD mode then that seems to be in conflict
with "adjunct to both modes is the Echo function". I think that the
proponents of this document must decide and clarify their position in
regard to the status of the BFD Echo Is it a mode or function in BFD
protocol? Then, resulting from the answer to that question, it will be
clear whether the proposal is complying with RFC 5880 or not.

>
> For all the proposed updates to the RFC 5880, it is not clear why in some
> proposed texts, both modes, Asynchronous, and Demand, are referenced but in
> some only the Asynchronous. For example, updates to Section 6.1, Section
> 6.4, and Section 6.8.3 refer only to the Asynchronous mode, while updates
> to Section 6.8 and Section 6.8.9 - refer to both BFD modes.
> XM>>> As I recall it, the reason is that some updated text applies to
> Asynchronous mode only, and some others applies to both modes.
>
GIM>> As I understand it, BFD Echo applies to both BFD modes - Asynchronous
and Demand. The text in RFC 5880 is clear about that in the following "An
adjunct to both modes is the Echo function." I think that these updates of
RFC 5880 are more confusing and not necessary. I propose removing them
altogether.

>
> In the second paragraph of Section 3 of the draft, the specification
GIM>> Thank you. In that case, I have a question. If the BFD Echo follows
the BFD state machine as defined in RFC 5880, sending BFD Echo before a BFD
session is in the Up state is a violation of:
   BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
   Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
   Control packet received from the remote system contains a nonzero
   value in Required Min Echo RX Interval.
So, hence my question

How the BFD session reaches the Up state?

> Further, in the third paragraph of Section 3, it appears that the BFD Echo
> function on device A starts transmitting BFD control packets once the
GIM>> I think that the first BFD Control packet in the Asynchronous mode is
sent with the Init state. According to RFC 5880, BFD Echo packets MUST NOT
be transmitted before the session reaches the Up state. I cannot find in
the draft an explanation of how the state machine progresses from Down to
Up state to allow a BFD Echo packet transmission.

>
> In the same first sentence of the third paragraph in Section 3, another
> recommendation reads as "SHOULD include a BFD Echo session demultiplexing
> field". I have questions similar to the recommendation in the second
> paragraph of Section 3:
> What happens if an implementation does not include that particular field
> in the transmitted packets? Is it still a BFD Echo? How then sessions are
> demultiplexed?
> XM>>> Is that possible an implementation uses IP five tuples to
> demultiplex the loopbacked packets? If not, I agree to change from SHOULD
> to MUST.
>
GIM>> I really don't know. I believe that the authors need to decide and
clarify in the specification.

>
> Now, I may have an alternative proposal that can produce the desired
> result and not require any update to RFC 5880. Please consider the
> following:
> RFC 8562 introduced a new type of the BFD session - MultipointHead. A
> Considering the above, a system that uses the Unaffiliated BFD Echo starts
> as MultipointHead with bfd.DesiredMinTxInterval set to the maximum value
> (or any sanely large enough). The exact construction of the periodic BFD
> Control packets transmitted by the MultipointHead needs some detailed
> In the meantime, because the BFD session for the MultipointHead started in
> the Up state, it can transmit BFD Echo packets according to RFC 5880 and
> RFC 8562.
> I think that if this proposal works, it may be moved as Informational
> since it describes the use of well-known BFD principles and mechanisms in
> an innovative and useful manner.
> XM>>> Although I'm unfamiliar with RFC 8562, while seeing BFD Demand mode,
> the first question came to my mind is that, can the peer system of
> MultipointHead be a BFD-unware device? That's the key requirement which
> results in Unaffiliated BFD Echo.
> Thank you again, Greg.
>
GIM>> RFC 8562 enables BFD peer(s), referred to as MultipointTail, to
monitor the MutipointHead and the continuity of the multipoint network. In
that scenario, the MultipointHead is not aware of the presence of any
MultipointTail. Thus, answering your question, the sender of BFD Control
packets, per RFC 8562, does not require its remote peer is BFD-capable.
Perhaps others would share their understanding of RFC 8562?

---

From: <[email-masked]>
Date: Thu, 18 Nov 2021 11:44:32 +0800 (CST)

Hi Greg,

Please see inline with [XM].

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：GregMirsky
收件人：肖敏10093570;
抄送人：[email-masked];rtg-bfd WG;
日 期 ：2021年11月17日 23:48
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Hi Xiao Min,thank you for your quick response to my questions and comments. Please find my follow-up notes in-lined below under the GIM>> tag.

Regards,
Greg

------------------原始邮件------------------
发件人：GregMirsky
收件人：[email-masked];rtg-bfd WG;
日 期 ：2021年11月17日 01:40
主 题 ：Several questions about the draft-ietf-bfd-unaffiliated-echo
Dear Authors,I've read the latest version and I have several questions. I greatly appreciate your insights and clarifications:
Firstly, what is being standardized by this specification? I couldn't find that the described process requires any cooperation, action from a remote BFD peer. As I can see, only the sender of BFD Echo packets is acting and thus every action, e.g., construction of the test probe, a method to demultiplex incoming test packets, etc., is internal to the sender. Hence, it appears that there is nothing to be standardized as all of it is internal processing that does not impact any other BFD system.
XM>>> The intention is to record a popular use of the BFD Echo function that doesn't comply with RFC 5880, at the same time this document does some clean-ups to RFC 5880.
GIM>> In my opinion, if something doesn't comply with the protocol, then it must be re-worked, not the protocol. If that is not possible, then, probably, that is not really a part of the protocol.
[XM] I don't think so. RFC 5880 has been updated by RFC 7419, RFC 7880 and RFC 8562. Any IETF RFC can be updated or even obsoleted.

The first update to RFC 5880 seems to suggest that the Echo function is an essential part of both Asynchronous and Demand modes of BFD. The original text of RFC 5880 characterizes the Echo function as an adjunct, i.e., a supplemental, function. The proposed new text - as a function that completes both BFD modes, makes them perfect, i.e., is an essential, necessary component. I think that that is not really the case and the BFD Echo function is not an essential, optional function of the BFD protocol.
XM>>> Does s/complement/supplement work for you?
GIM>> That is better but "adjunct" has the same meaning as "complement". I propose removing "complement" altogether and, as the result, leaving the text in RFC 5880 unchanged.
[XM] To my understanding, "adjunct" implies BFD Echo is dependent, however Unaffiliated BFD Echo is independent, so this update is needed.

The last sentence in the next proposed update to the RFC 5880 concerns me:
The Echo function may also be used independently, with neither Asynchronous nor Demand mode.
It appears that, if accepted, the BFD Echo function is transformed into an additional BFD mode. If that is the case, then this specification, in my opinion, is not updating the RFC 5880 but is defining a new protocol.
XM>>> I tend to agree that the Unaffiliated BFD Echo can be seen as a new BFD mode, however I don't think it's defining a new protocol, it's definitely based on BFD protocol.
GIM>> If the BFD Echo is a new BFD mode then that seems to be in conflict with "adjunct to both modes is the Echo function". I think that the proponents of this document must decide and clarify their position in regard to the status of the BFD Echo Is it a mode or function in BFD protocol? Then, resulting from the answer to that question, it will be clear whether the proposal is complying with RFC 5880 or not.
[XM] As I said above, "adjunct" needs to be updated. In addition, I tend to agree it's a new BFD mode, however a new BFD mode looks a bit heavy to be documented, my proposal is to call it just "Unaffiliated BFD Echo", remove "function" from its name.

For all the proposed updates to the RFC 5880, it is not clear why in some proposed texts, both modes, Asynchronous, and Demand, are referenced but in some only the Asynchronous. For example, updates to Section 6.1, Section 6.4, and Section 6.8.3 refer only to the Asynchronous mode, while updates to Section 6.8 and Section 6.8.9 - refer to both BFD modes.
XM>>> As I recall it, the reason is that some updated text applies to Asynchronous mode only, and some others applies to both modes.
GIM>> As I understand it, BFD Echo applies to both BFD modes - Asynchronous and Demand. The text in RFC 5880 is clear about that in the following "An adjunct to both modes is the Echo function." I think that these updates of RFC 5880 are more confusing and not necessary. I propose removing them altogether.
[XM] I disagree. We need these updates to make Unaffiliated BFD Echo complied with RFC 5880. If you have concern on any specific update, please raise it up, and then we can dig into the details.

In the second paragraph of Section 3 of the draft, the specification recommends that an implementation supporting this draft follows the BFD state machine, as defined in RFC 5880. Why is it a recommendation and not a requirement? And further, if an implementation does not follow the BFD state machine, is it still BFD?
XM>>> Make sense. I think we can make it a requirement instead of recommendation.
GIM>> Thank you. In that case, I have a question. If the BFD Echo follows the BFD state machine as defined in RFC 5880, sending BFD Echo before a BFD session is in the Up state is a violation of:
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval.
So, hence my question
How the BFD session reaches the Up state?
[XM] That's why I disagree with your proposal to remove all the updates to RFC 5880. I've noticed the text you quoted from RFC 5880 and made an update, please take a look at Section 2 of this draft. As to your question, please take a look at last paragraph of Section 3 of this draft, if it's still not clear, please let me know and I can improve it.

Further, in the third paragraph of Section 3, it appears that the BFD Echo function on device A starts transmitting BFD control packets once the session is created. What is the state of the created BFD Echo session? As I understand it, the BFD state machine starts from the Init. Isn't that the case for this document as well?
XM>>> No change to the BFD state machine. As I understand it, it's DOWN state.
GIM>> I think that the first BFD Control packet in the Asynchronous mode is sent with the Init state. According to RFC 5880, BFD Echo packets MUST NOT be transmitted before the session reaches the Up state. I cannot find in the draft an explanation of how the state machine progresses from Down to Up state to allow a BFD Echo packet transmission.
[XM] Acc to my reading on Section 6.2 of RFC 5880, the first BFD Control packet in the Asynchronous mode is sent with *Down* state, not *Init* state.

In the same first sentence of the third paragraph in Section 3, another recommendation reads as "SHOULD include a BFD Echo session demultiplexing field". I have questions similar to the recommendation in the second paragraph of Section 3:
Why is it a recommendation and not a requirement?
What happens if an implementation does not include that particular field in the transmitted packets? Is it still a BFD Echo? How then sessions are demultiplexed?
I greatly appreciate your consideration and help in clarifying these aspects of the draft.
XM>>> Is that possible an implementation uses IP five tuples to demultiplex the loopbacked packets? If not, I agree to change from SHOULD to MUST.
GIM>> I really don't know. I believe that the authors need to decide and clarify in the specification.
[XM] OK, I'll discuss it with my co-authors and act on the draft in the next rev.

GIM>> RFC 8562 enables BFD peer(s), referred to as MultipointTail, to monitor the MutipointHead and the continuity of the multipoint network. In that scenario, the MultipointHead is not aware of the presence of any MultipointTail. Thus, answering your question, the sender of BFD Control packets, per RFC 8562, does not require its remote peer is BFD-capable. Perhaps others would share their understanding of RFC 8562?

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 18 Nov 2021 09:29:45 -0500

I owe the commenters in this thread a detailed response in the near future.
However, I did want to highlight the underlying motivation the Working Group
had to pick up this work.

On Wed, Nov 17, 2021 at 05:00:09PM +0800, [email-masked] wrote:
> responsible AD and WG chairs, we realized that an informational draft
> might be the proper way to record our implementation and deployment. And
> then, during the adoption poll of this draft, there was rough consensus
> that this draft should be adopted as standards track document, so we
> changed the intended status from informational to standards track.

A core motivation for this work is to provide an IETF standardized profile
of what is typically shipped as Broadband Forum (BBF) TR-146.  That
mechanism, effectively running a BFD-aware system with a system that does
NOT implement BFD but able to provide BFD Echo loopback mode.  Arguably,
this is one step better than running ping and significantly better from a
monitoring standpoint since BFD machinery can be leveraged on the side that
supports it for creating events.

TR-146 wasn't as clearly specified as we tend to like in IETF BFD work, so
we're doing a flavor of that here.

Prior discussion with our AD of the time suggested that this is targeted
toward Standards Track.  But like all IETF work, once we've completed the
draft, we may consider whether that classification remains correct.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 18 Nov 2021 07:10:18 -0800

Adding BBF Liaison officer David Sinicrope to the discussion.

I have a question regarding the BBF's interest in this work.
Had IETF and the BFD WG received an official liaison from BBF regarding its
interest in standardizing the mechanism mentioned in TR-146? If not, how
the BFD WG has concluded that BBF has any interest in that work?

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 18 Nov 2021 10:42:09 -0500

Thank you, Greg.  While I was in the process of responding to a similar inquiry from Joel Halpern I was about to comment that I believe I had discussion with David about this proposal over lunch at an IETF.

The items that made it into formal IETF record for bfd unaffiliated:
This work was originally presented in IETF 106.  There was a note about checking on IPR considerations:
https://datatracker.ietf.org/doc/minutes-106-bfd/ <https://datatracker.ietf.org/doc/minutes-106-bfd/>

The adoption call thread was here:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/iHmoi-VS1bRn8_m7OdSbJ3mdPMg/ <https://mailarchive.ietf.org/arch/msg/rtg-bfd/iHmoi-VS1bRn8_m7OdSbJ3mdPMg/>

My lunch discussion with David did not make it into any formal minutes.  That's likely a mistake.

Let's see what David recalls from that discussion.

-- Jeff

> On Nov 18, 2021, at 10:10 AM, Greg Mirsky <[email-masked]> wrote:
> 
> Had IETF and the BFD WG received an official liaison from BBF regarding its interest in standardizing the mechanism mentioned in TR-146? If not, how the BFD WG has concluded that BBF has any interest in that work?
> 
> Regards,
> Greg
> 
> On Thu, Nov 18, 2021 at 6:29 AM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Nov 17, 2021 at 05:00:09PM +0800, [email-masked] <mailto:[email-masked]> wrote:

---

From: David Sinicrope <[email-masked]>
Date: Thu, 18 Nov 2021 17:18:38 +0000

Thanks Jeff.
Sorry, I don't recall our discussion, but then it would have been as long ago as Singapore in Nov 2019 or before.
(Is it possible you spoke with Dave Allan?)

I can say as the BBF Liaison Manager there have been many past claims of BBF interest in IETF work without substantiation.  As a result, it has been key to ensure that any statement of BBF interest in IETF work, especially if made to encourage action in the IETF, be formally supported via a liaison.    Searching the Liaison Statements in Datatracker<https://datatracker.ietf.org/liaison/>, I don't see a liaison from either the BBF or IETF related to this work.

Also, to the best of my knowledge, the issues that this draft addresses have not been raised in BBF. E.g., a proposal for revision to TR-146 or related documents.

Given the stated overlap and application of the draft to TR-146 (in the adoption call),

It should be noted that this document overlaps work in the Broadband Forum
(BBF) document TR-146.  As noted in the presentation, the BBF document lacks
some clarity and also doesn't discuss interactions with BFD implementations.
This draft has good clarifications with regard to implementations of this
mechanism when the a BFD Echo-capable implementation is used.
I would suggest that a liaison be crafted and sent to the BBF formally notifying them of this work and inquiring as to the interest in the content of the draft.  Fortunately, the next BBF meeting where such a liaison would be addressed and responded to is 29 Nov - 3 Dec 2021.  The sooner the liaison is sent, the more likely a timely response coming out of this upcoming meeting.

I hope this information is helpful despite the lack of recollection of our discussion.
Thanks,
Dave

From: Jeffrey Haas <[email-masked]>
Sent: Thursday, November 18, 2021 10:42 AM
To: Greg Mirsky <[email-masked]>
Cc: David Sinicrope <[email-masked]>; David Sinicrope <[email-masked]>; Xiao Min <[email-masked]>; rtg-bfd WG <[email-masked]>; [email-masked]
Subject: Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

The items that made it into formal IETF record for bfd unaffiliated:
This work was originally presented in IETF 106.  There was a note about checking on IPR considerations:
https://datatracker.ietf.org/doc/minutes-106-bfd/

The adoption call thread was here:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/iHmoi-VS1bRn8_m7OdSbJ3mdPMg/

-- Jeff

On Nov 18, 2021, at 10:10 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Greg

On Thu, Nov 18, 2021 at 6:29 AM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
I owe the commenters in this thread a detailed response in the near future.
However, I did want to highlight the underlying motivation the Working Group
had to pick up this work.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 18 Nov 2021 12:38:02 -0500

David,

> (Is it possible you spoke with Dave Allan?)

That's possible!  As I noted in the thread, my notes from that lunch are
missing.  (I have strong words for Microsoft about their support for Mac
mail, but that's a different story.)  Whomever I had a conversation with it
was in a subterranean warren of lunch venues.  Perhaps that will jar
someone's memory of the venue.

If you have contact info for Dave Allen I can certainly followup with him.

> I can say as the BBF Liaison Manager there have been many past claims of
> BBF interest in IETF work without substantiation.  As a result, it has
> been key to ensure that any statement of BBF interest in IETF work,
> especially if made to encourage action in the IETF, be formally supported
> via a liaison.    Searching the Liaison Statements in
> Datatracker<https://datatracker.ietf.org/liaison/>, I don't see a liaison
> from either the BBF or IETF related to this work.

Please note that I don't believe we're asserting that BBF is interested in
IETF in doing this work for BBF.  And perhaps the easiest answer we'll
converge to is "remove all mention of BBF".

That said, throughout the discussion that lead to this draft, it was pointed
out to the original authors that they were largely covering the TR-146 use
case.  Minimally, making sure we have a BBF statement regarding the IETF
work may make sense.

> Also, to the best of my knowledge, the issues that this draft addresses
> have not been raised in BBF. E.g., a proposal for revision to TR-146 or
> related documents.

I am not a participant in BBF and have no knowledge of any such
communications one way or the other.  Informally, the discussions I have
been involved in both with the BFD draft in question and in prior contexts
at my employer have mostly been that the BBF procedures are somewhat
inspecific and cleaner documented procedures for the use case are desired.

> Given the stated overlap and application of the draft to TR-146 (in the adoption call),
[...]
> I would suggest that a liaison be crafted and sent to the BBF formally
> notifying them of this work and inquiring as to the interest in the
> content of the draft.  Fortunately, the next BBF meeting where such a
> liaison would be addressed and responded to is 29 Nov - 3 Dec 2021.  The
> sooner the liaison is sent, the more likely a timely response coming out
> of this upcoming meeting.

I think we could make such a deadline.  I'll start discussion with our AD to
see what the IESG will want for the liaison statement.

Meanwhile, I'll see if I can contact Dave Allen to try to get clarification
of what we discussed over lunch - if it was him.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 18 Nov 2021 12:47:08 -0500

> If you have contact info for Dave Allen I can certainly followup with him.

Terse followup:
It was indeed Dave Allan I had lunch with in July 2018 at IETF 102 in
Montreal.  This has lead me to a cache of previous emails.  More followup
today.

-- Jeff

---

From: David Sinicrope <[email-masked]>
Date: Thu, 18 Nov 2021 13:05:01 -0500

Hi Jeff, (Sorry for bouncing around email addresses on you… IT challenges
this week)

Thanks for clarifying the assertion concerning BBF interest.  Still, given
the statement in the adoption call and the clear references to TR-146 in
the draft, it would be a good idea to liaise to BBF, even if brief, and let
them know of the draft and its relation to TR-146.  It certainly couldn’t
hurt to have open communication with them on the subject.

Regarding your check with the IESG on the liaison - please proceed as you
deem appropriate.  I will say, (and apologies if I’m stating well known
details) that typically liaisons don’t need IESG approval.  They are
normally crafted/drafted by the WG Chairs, and have some level of review
and approval by the WG(s) in question or impacted.

I hope this helps find the most expeditious and effective way to proceed.
Thanks,
Dave

On Thu, Nov 18, 2021 at 12:38 Jeffrey Haas <[email-masked]> wrote:

> > Sorry, I don't recall our discussion, but then it would have been as
> long ago as Singapore in Nov 2019 or before.
-- 
David Sinicrope
[email-masked]

---

From: <[email-masked]>
Date: Fri, 19 Nov 2021 10:15:08 +0800 (CST)

Thank you Jeff! A very clear description on the core motivation and current situation.
>From the author's perspective, I'd like to remove the reference to BBF TR-146 if it's becoming a blocking issue instead of a supporting argument.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：[email-masked];[email-masked];[email-masked];
日 期 ：2021年11月18日 22:29

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 19 Nov 2021 08:23:25 -0500

Xiao Min,

> From the author's perspective, I'd like to remove the reference to BBF TR-146 if it's becoming a blocking issue instead of a supporting argument.

My recommendation is we leave that text alone for the time being.  Since the
feature is inspired by it, we'll likely want to discuss it in the document
long term - even if to contrast how it's both similar and different.

BBF as an organization may request us to remove the text, or perhaps offer
other positions on the document's fate.  We'll be sending a liaison
statement to BBF probably next week.  Thanks to Greg and Joel for motivating
this past-due bit of followup.

-- Jeff

---

From: <[email-masked]>
Date: Mon, 22 Nov 2021 10:21:41 +0800 (CST)

Jeff,

That's OK. I'll hold on for your further judgement.
Just to clarify, when this document's predecessor (draft-wang-bfd-one-arm-use-case-00) was brought up to IETF, the proponents didn't know any of BBF related prior art, that means their original work was not inspired by BBF TR-146. At that time, the proposed deployment scenario was DC network but not broadband access network, more specifically, BFD Echo running between DC-GW and VM.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：[email-masked];[email-masked];[email-masked];
日 期 ：2021年11月19日 21:23
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Xiao Min,
On Fri, Nov 19, 2021 at 10:15:08AM +0800, [email-masked] wrote:
> From the author's perspective, I'd like to remove the reference to BBF TR-146 if it's becoming a blocking issue instead of a supporting argument..

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Nov 2021 17:10:31 -0500

Greg, Xiao Min,

Picking one small section of the replies as the basis of my own reply:

> clear whether the proposal is complying with RFC 5880 or not.

The original versions of the document changes were primarily targeted toward
updating text that forbade echo mode from running when a session was not in
the Up state.

The point that you're making, Greg, is a fair one: This draft is attempting
to have portions of a BFD state machine signaled through the Echo port but
is missing normative procedure.

The desired behavior is "obvious".  If you support BFD Echo, you'd like to
turn on that code to the remote system and do so without letting Echo be
initiated using the Async procedures.  However, since Echo is intentionally
under-documented in the BFD RFCs and is expected to have a paired async
session, this leaves the proposal missing quite a bit.

As an example, the three states of the RFC 5880 state machine assume the
ability to transition states based on hearing one's own discriminator echoed
in the Your Discriminator field.  This Discriminator swapping would not
happen for Echo.  This is where even a more closely analogous S-BFD (RFC 7880) 
procedure would break down.  

That said, S-BFD provides probably a closer experience to what is the
desired behavior.

The question the authors have is effectively, "given the presence of an IP
stack capable of supporting BFD Echo packet looping, how do I specify the
least procedure to have enough of BFD for my client stack to use and change
the least code possible?

-- Jeff

---

From: <[email-masked]>
Date: Tue, 23 Nov 2021 15:23:46 +0800 (CST)

Jeff,

I agree to your analysis.
In the current draft, I've tried to make the desired behavior clear, at the same time, reuse the already defined BFD procedure as much as possible.
As always, I'm open to any suggestions and comments. Although I disagree to a specific suggestion sometimes, the process of discussion is necessary and valuable.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：JeffreyHaas
收件人：Greg Mirsky;
抄送人：肖敏10093570;rtg-bfd WG;[email-masked];
日 期 ：2021年11月23日 06:10
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Greg, Xiao Min,
Picking one small section of the replies as the basis of my own reply:

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Nov 2021 09:21:42 -0800

Hi Jeff,
thank you for the continued technical discussion. I've added my notes below
in-line under the GIM>> tag.

Regards,
Greg

> session, this leaves the proposal missing quite a bit.
GIM>> I've proposed to consider using RFCs 8562/8563 as a starting point. A
MultipointHead operates in the Demand mode, does not use the three-way
handshake, and the BFD state machine is Up with the first transmitted BFD
Control packet. True, the use of the BFD Echo function is not described in
RFCs 8562/8563 but I don't expect it would present a serious problem to the
group. The advantage of making the unaffiliated BFD Echo an extension of
RFCs 8562/8563, in my opinion, is that the transmitted by MultipointHead
BFD Control packets, though go unprocessed, would nolt affect anything. The
rate of transmission can be one in an hour, one a day. And the BFD Echo
function is not required to bring the BFD session state Up but can be used
to detect the failure.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Nov 2021 14:43:24 -0500

Greg,

> function is not required to bring the BFD session state Up but can be used

A place where I consider the multipoint functionality to be an awkward fit
is that there's expected to be two participant roles: the head and the tail.
For an echo solution, the local system is BOTH head and tail.

This is contrasted vs. S-BFD where the Initiator expects to hear its own
stuff back from the reflector.

Valid points of comparison include that with multipoint the packets are not
expected to be changed, but S-BFD procedure requires that the Reflector flip
the discriminators.

It can be observed that the state machines for S-BFD and multipoint are
largely the same, with a slight simplification for S-BFD not having to deal
with the Down state.  IMO, the S-BFD state machine is closer to what we're
looking for.

Observations flipping through RFC 7880 with regard to what would likely need
to change to be the basis for bfd-unaffiliated pdus:

The roles of Initiator and Reflector are still clear - although reflector is
more literal.

You'd still want to have network-wide discriminator pools to help reduce
diagnostic headache if an Initiator get someone else's packet
inappropriately.  

We'd want a new SessionType

We'd still want to set demand mode.

The demultiplexing critieria would need to map to a session based on the
transmitted discriminators.  HOWEVER, some normative text would be required
on something we don't standardize - BFD Echo format in 5880, etc.  In
particular, the Initiator has to make sure you can distinguish received
Echo packets as being associated with a BFD unaffiliated session perhaps
distinctly from other Echo packets.  

The responder/reflector procedure is largely eliminated - this is BFD Echo
as per RFC 5880.

Many of the initiator procedures need mild tweaks because we are talking to
ourselves rather than an active reflector.

The S-bfd echo function section provides some wisdom on the security issues
with bfd unaffiliated.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Nov 2021 13:17:10 -0800

Hi Jeff,
I agree that S-BFD may provide a more suitable architectural framework for
the Unaffiliated Echo (would that then be referred to as Unaffiliated S-BFD
Echo?). Though, reading the S-BFD Echo Function section in RFC 7880, I find
that the specification allows using standalone S-BFD Echo without
periodically transmitted S-BFD Control packets. It seems precisely what is
the Unaffiliated Echo.

Regards,
Greg

---

From: <[email-masked]>
Date: Wed, 24 Nov 2021 11:36:38 +0800 (CST)

Greg, Jeff,

It looks that you converge on comparison between S-BFD Echo and Unaffiliated Echo.
What I want to point out is, allowing using standalone BFD/S-BFD Echo without periodically transmitted BFD/S-BFD Control packets, doesn't mean it's Unaffiliated Echo.
In RFC 5880 section 3.2 the 4th paragraph, it says
"Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode)."

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：GregMirsky
收件人：Jeffrey Haas;
抄送人：肖敏10093570;rtg-bfd WG;[email-masked];
日 期 ：2021年11月24日 05:17
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Hi Jeff,I agree that S-BFD may provide a more suitable architectural framework for the Unaffiliated Echo (would that then be referred to as Unaffiliated S-BFD Echo?). Though, reading the S-BFD Echo Function section in RFC 7880, I find that the specification allows using standalone S-BFD Echo without periodically transmitted S-BFD Control packets. It seems precisely what is the Unaffiliated Echo.

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Nov 2021 07:32:19 -0500

Xiao Min,

BFD Echo, completely underspecified in RFC 5880, is fine with that lack of detail when it is paired with an Async session.

For the unaffiliated case and no Async session to help provide correlating activities, some of the work of Async will need to be done in the Echo stream itself.  These things would include:
- Security - why do I believe this is for my session?
- Session demultiplexing - why do I believe this is an Echo packet for one session instead of another?

The only option you have for Echo is "I can hear myself".  The question becomes what data you encode in there that covers at least those properties.

It's likely that some existing BFD Echo implementations already achieve this through proprietary means.  Some implementors may have chosen to simply encode a BFD Async packet in the Echo stream since they already have code that can deal with such packets.

If so, the question that needs answered is procedure for dealing with those packets.  We have several extensions to BFD that discusses ways that can be done.  This is the reason for comparison vs. existing mechanisms.

-- Jeff

> On Nov 23, 2021, at 10:36 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Greg, Jeff,
>

---

From: <[email-masked]>
Date: Thu, 25 Nov 2021 11:03:16 +0800 (CST)

Jeff,

I have no objection to the comparison, please go on.
One thing I want to emphasize is that, whether DC use case (brought up by draft-wang-bfd-one-arm-use-case) or broadband access use case (brought up by BBF TR-146), the key requirement is that the peer system is totally BFD-Unaware, in other words, the peer system would never send or parse any BFD Control packets, from the very beginning.
Another thing is that the Unaffiliated BFD Echo can only work between the local system and its one-hop-away peer system.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：Greg Mirsky;rtg-bfd WG;[email-masked];
日 期 ：2021年11月24日 20:32

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Nov 2021 07:37:20 -0500

> One thing I want to emphasize is that, whether DC use case (brought up by draft-wang-bfd-one-arm-use-case) or broadband access use case (brought up by BBF TR-146), the key requirement is that the p…

This has been consistent with everything I've seen over the last several
years and will be a fine requirement.

(I had been asked about a similar mechanism almost two years before someone
showed me the BBF document.)

> Another thing is that the Unaffiliated BFD Echo can only work between the local system and its one-hop-away peer system.

For IPv4/IPv6 unicast, that's consistent with BFD Echo procedures.

-- Jeff

---

From: <[email-masked]>
Date: Fri, 26 Nov 2021 10:19:37 +0800 (CST)

Jeff,

So, that's not new to everyone, great!
At this time, my proposal is to proceed with draft-ietf-bfd-unaffiliated-echo, publish it as planned.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：JeffreyHaas
收件人：肖敏10093570;
日 期 ：2021年11月25日 20:37