Subject: Session IP address changes

From: Chris Nogradi <[email-masked]>
Date: Thu, 10 Mar 2005 16:24:04 -0500

Dave,

the base BFD draft in section 6.3 paragraph 3 suggests that a BFD peer could 
decide to change its IP address and that this change would be transparent to 
the running BFD session since it is demultiplexing based on the 
discriminator.  However, it would seem that the receiving node would have to 
react to this change by sending all BFD packet for this session to the new 
address in order to guarantee that the session does not go down.  If this is 
the case, it would seem that it would be beneficial to require nodes to send 
a BFD packet with the new address as soon as it is changed to ensure that the 
peer is quickly made aware of the change.  It would also be important to 
document in the packet reception processing the point at which the new 
address should start being used (I assume at the same time the peer 
discriminator is set).  One scenario I would think that would benefit from 
this is for IS-IS neighbors.   

For OSPF and eBGP, the session staying up in the event of an IP address 
change, should not matter as the adjacencies will be torn down anyway. But in 
the case of static routes, if the address of the peer changes, the BFD 
session should go down.  Seeing that this is the case, it would seem 
appropriate to only allow the IP address change when ALL routing protocols 
using the BFD session support it or don't care.

What do you think?

Thanks,

Chris

---

From: Dave Katz <[email-masked]>
Date: Thu, 10 Mar 2005 15:58:47 -0700

This scenario was intended to deal with the particular case of running 
BFD on an unnumbered IP interface, where the source address of packets 
may be unpredictable and may change, but there is nothing amiss with 
the BFD session.  Since there was this possibility in the particular 
case, it became useful to generalize it.

Note that you're referring to the base spec;  it says nothing about IP 
or the interactions with particular protocols or the address to which 
packets are sent;  these are issues for the application specs.  All it 
says is that received packets must be demuxed solely by the Your Discr 
field, which is all that it should say IMHO.  Remember, the 
functionality mandated here will apply to all future applications of 
the protocol (non-IP, non-network-layer, etc.) for which our IP-centric 
view of addressing may not apply.

The 1hop spec is pretty clear on addressing;  if the link is numbered, 
the addresses must be stable.  In the unnumbered case, it allows 
address flexibility.  Adding note in section 6 of that document 
specifying that the dest address must be set to the source address of 
the received packet in that case is probably a good idea.  (Note that 
if the system persists in using the old address, either it will work 
because the address is valid, or the session will fail, and in either 
case should probably converge on the right thing.)

I don't want to get into attempting to specify operations based on a 
nebulous characteristic of one or more of the clients using the 
session;  rather, what I think I will do is to note that an 
implementation MAY signal the fact that the address changed to the 
clients, and let them deal with the fallout as they see fit.  If an 
application decides it is fatal, it can always tear down the session.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Thu, 10 Mar 2005 18:17:43 -0700

Actually I thought about this a bit more, and came to the conclusion 
that the spec should say that the BFD implementation must continue to 
use the configured destination address (given by the client when 
setting up the session) and that the fact that packets are arriving 
from a new source address SHOULD be communicated to the client(s) so 
they can decide what to do.

The dest address is a parameter in the API, and BFD should not be 
changing it of its own accord.

--Dave

On Mar 10, 2005, at 3:58 PM, Dave Katz wrote:

> the protocol (non-IP, non-network-layer, etc.) for which our 
> IP-centric view of addressing may not apply.
>