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) <ginsb...@cisco.com> > wrote: > > 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 > > >> -----Original Message----- >> From: Naiming Shen (naiming) >> Sent: Monday, October 29, 2018 6:58 PM >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> >> Cc: Jeffrey Haas <jh...@pfrc.org>; rtg-bfd@ietf.org; draft-chen-bfd- >> unsolici...@ietf.org >> Subject: Re: WG Adoption for draft-chen-bfd-unsolicted >> >> >> 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) <ginsb...@cisco.com> >> wrote: >>> >>> 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 <rtg-bfd-boun...@ietf.org> On Behalf Of Jeffrey Haas >>>> Sent: Monday, October 29, 2018 8:53 AM >>>> To: rtg-bfd@ietf.org >>>> Cc: draft-chen-bfd-unsolici...@ietf.org >>>> Subject: WG Adoption for draft-chen-bfd-unsolicted >>>> >>>> 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 >>> >
