Re: Session IP address changes
Dave Katz <dkatz@juniper.net> Fri, 11 March 2005 01:18 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28963; Thu, 10 Mar 2005 20:18:31 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9YqO-0002mE-4w; Thu, 10 Mar 2005 20:21:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Yml-0002We-4d; Thu, 10 Mar 2005 20:17:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Ymi-0002WU-GI for rtg-bfd@megatron.ietf.org; Thu, 10 Mar 2005 20:17:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28827 for <rtg-bfd@ietf.org>; Thu, 10 Mar 2005 20:17:44 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Ypc-0002f5-OV for rtg-bfd@ietf.org; Thu, 10 Mar 2005 20:20:49 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j2B1HcBm079692; Thu, 10 Mar 2005 17:17:38 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2B1Hce99950; Thu, 10 Mar 2005 17:17:38 -0800 (PST) (envelope-from dkatz@juniper.net)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <f0b44721c71fcefe0861f20200cf30ab@juniper.net>
References: <200503101624.04503.cnogradi@laurelnetworks.com> <f0b44721c71fcefe0861f20200cf30ab@juniper.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <3909cc406c7ac17dc576c7c10432539d@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Thu, 10 Mar 2005 18:17:43 -0700
To: Chris Nogradi <cnogradi@laurelnetworks.com>, "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Subject: Re: Session IP address changes
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: 7bit
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: > 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 > > > > On Mar 10, 2005, at 2:24 PM, Chris Nogradi wrote: > >> 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 >> > >
- Session IP address changes Chris Nogradi
- Re: Session IP address changes Dave Katz
- Re: Session IP address changes Dave Katz