RE: Discovering IP address to use for uBFD sessions

["Nobo Akiya (nobo)" <[e-mail]>]

Binny, Glen, thank you both for valuable comments.

Unfortunately, we are not seeing significant interest in either direction.

It may be more unrewarding to call for dynamic discovery mechanism work continuation without significant interest.

I hope to hear more comments on this topic from others, both supporting and not supporting dynamic discovery, to allow for more accurate call to be made.

Regards,
Nobo

From: Binny Jeshan [mailto:[e-mail]]
Sent: Tuesday, June 25, 2013 3:37 AM
To: Nobo Akiya (nobo); Glen Kent; Bhatia, Manav (Manav)
Cc: [e-mail]
Subject: RE: Discovering IP address to use for uBFD sessions

Hello all,

I too have come across the products and discussions that focused on static configurations so far, but this one seems interesting looking from simplified operations point of view. I
Personally would be interested in simplified operations of BFD, but I would be more preferring any out-of-band mechanisms to do that, depending on the technology where BFD is used can offer to it. One similar way that I remember is LSP Ping BFD bootstrapping done in MPLS. BFD should/preferably-better depend on its higher control plane to give the discovered data to BFD.

IMHO, lets continue to work on this.

Regards, Binny
Aricent, India

Sent from Nokia Lumia
________________________________
From: Nobo Akiya (nobo)<mailto:[e-mail]>
Sent: ‎22-‎06-‎2013 04:33 AM
To: Glen Kent<mailto:[e-mail]>; Bhatia, Manav (Manav)<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Discovering IP address to use for uBFD sessions
Hello Manav, Glen, et al,

[hat on]

Primary discussion on the thread seemed to have revolved around which discovery mechanism is preferred (multicast vs. 127/8). There was also a preference of static configuration approach, to allow for faster implementation.

Based on number of responses on the thread, one can argue there was interest in auto discovery approach back then.

Now that several vendors have implement BFD on LAG, and using static configuration approach, it would be beneficial to see if there is still significant interest for auto discovery approach or if interest have shifted.

Can people (vendors, operators, others) kindly chime in?

[hat off]

Products that I know has proprietary but very similar to BFD on LAG solution, has static configuration approach, and have been used for years. I have not seen any auto discovery requests. Thus I personally think static configuration is an acceptable approach, and my preference is to go with last paragraph/sentence of Manav’s email.

Regards,
Nobo


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Glen Kent
Sent: Thursday, June 20, 2013 1:31 PM
To: Bhatia, Manav (Manav)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Discovering IP address to use for uBFD sessions

Hi Manav,

We did have a discussion around this more than a year back here:
http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01294.html

There clearly was interest in pursuing something like this.

I agree that we should have some mechanism to discover the remote IP addresses.

Glen

On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Manav) <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD sessions is derived/learnt/discovered.

It wisely assumes that an out-of-band mechanism exists which arms the routers with the knowledge about the remote IP address that it must use to establish the micro BFD session.

Some time back few of us wrote a short draft - draft-mmsn-bfd-on-lags-address-00, that describes how routers can obtain/discover remote IP addresses required for establishing uBFD sessions.

I would like the WG members to go through the above draft and discuss whether we need a draft that describes alternate ways to discover remote IP addresses or can we all assume that the remote IP addresses MUST be statically configured.

The problem with implicitly assuming that the remote IP addresses MUST be configured is that as more folks start implementing this, they would stumble upon this issue and would be left clueless on how the IP addresses have to be derived. In case the WG decides that its premature to work on an autodiscovery mechanism, I would still like us to publish a draft that says that addresses MUST be statically configured and an Appendix where alternate mechanisms are listed along with their pros and cons (mostly for the sake of posterity).

Cheers, Manav