Subject: WG Adoption for draft-chen-bfd-unsolicted

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Oct 2018 11:52:32 -0400

Working Group,

Reviewing my notes, I was remiss in sending out an adoption request for
draft-chen-bfd-unsolicted (Unsolicited BFD for Sessionless Applications).

https://datatracker.ietf.org/doc/draft-chen-bfd-unsolicited/

This relatively minor change from the RFC 5880 spec is implemented by at
least one vendor for static route configuration.  Its security
considerations already cover what I believe to be the main concern with the
procedural change.

There's a minor point to resolve regarding the document's status - currently
Informational - with our AD.

Please indicate whether you'd support adopting this draft as a Working Group
document.

Authors, please indicate if you're aware of any applicable IPR on it.

This adoption request will also end on Friday, November 9, IETF 103 Friday.

-- Jeff & Reshad

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 29 Oct 2018 19:50:39 +0000

Hi Jeff, 
I have read the draft and support WG adoption.
Thanks,
Acee

On 10/29/18, 11:53 AM, "Rtg-bfd on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Working Group,

    

    

    -- Jeff & Reshad

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Mon, 29 Oct 2018 21:32:02 +0000

Support as a co-author.

Regards,
- Naiming

> On Oct 29, 2018, at 8:52 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Working Group,
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 29 Oct 2018 15:04:20 -0700

Yes/support
Makes sense, in Redback times we had a design to build it that way (never did though), not an IPR disclosure .

Cheers,
Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 29 Oct 2018 23:52:53 +0000

The problem the draft addresses is valid and makes sense to address. But I know there are implementations which have addressed this issue w/o requiring any changes to their BFD implementation - so I am not sure how popular this solution will be.

So long as this stays Informational I think it is fine to adopt. I would not be as enthused if this is moved to Standards track.

   Les

> -----Original Message-----
> From: Rtg-bfd <[email-masked]> On Behalf Of Jeffrey Haas
> Sent: Monday, October 29, 2018 8:53 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: WG Adoption for draft-chen-bfd-unsolicted
> 
> Working Group,
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Tue, 30 Oct 2018 01:58:09 +0000

I’m not aware of an implementation taking in the inbound BFD packets,
then dynamically seting up a session to the received packet sender end-point.
As Jeff mentioned Redback planed on this, but didn’t implement. So there most
likely needs some BFD implementation changes.

Regards,
- Naiming

> On Oct 29, 2018, at 4:52 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 30 Oct 2018 03:42:27 +0000

Naiming -

I did not say that implementations had done exactly what you propose in this draft. I said:

" there are implementations which have addressed this issue w/o requiring any changes to their BFD implementation"

There is more than one way to solve this problem. :-)

I raise this point because an implementation which has already addressed the issue has little motivation to move to a different solution (such as you propose).
Which is why I am OK if this is merely informational - but not otherwise.

   Les

> From: Naiming Shen (naiming)
> Sent: Monday, October 29, 2018 6:58 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>; [email-masked]; draft-chen-bfd-
> [email-masked]
> Subject: Re: WG Adoption for draft-chen-bfd-unsolicted
> 
> 
> > The problem the draft addresses is valid and makes sense to address. But I
> know there are implementations which have addressed this issue w/o
> requiring any changes to their BFD implementation - so I am not sure how
> popular this solution will be.
> >
> > So long as this stays Informational I think it is fine to adopt. I would not be
> as enthused if this is moved to Standards track.
> >
> >   Les
> >
> >

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Tue, 30 Oct 2018 22:28:15 +0000

Les,

Just to clarify. There is not a “this issue”, there are multiple issues;-)

I think you are referring to the case of static routing BFD usage without requiring
the neighbor to install a bogus static route towards us.

But the main application here is in the public peering site, the BFD sessions can
be setup dynamically using this draft to avoid black hole traffic, the BGP peering
relation (needs configuration) is only with the RR server.

Regards,
- Naiming

> On Oct 29, 2018, at 8:42 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Naiming -
>