Subject: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt

From: [email-masked]
Date: Thu, 16 Sep 1999 07:00:04 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPNG Working Group of the IETF.

	Title		: Multihomed routing domain issues for IPv6 
                          aggregatable  scheme                 
	Author(s)	: F. Dupont
	Filename	: draft-ietf-ipngwg-multi-isp-00.txt
	Pages		: 13
	Date		: 15-Sep-99
	
This document exposes some issues for multihomed routing domains using
the aggregatable addressing and routing scheme. A routing domain is
multihomed when it uses two or more providers of the upper level. Most
of these issues are not specific to IPv6 but are consequences of the
addressing and routing scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-multi-isp-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipngwg-multi-isp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-multi-isp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Richard Draves <[email-masked]>
Date: Thu, 23 Sep 1999 08:42:29 -0700

> It was specifically made to apply only to the valid lifetime as
> resetting that to 0 has immediate fatal consequences. In contrast,
> tinkering with the preferred lifetime shouldn't break things. I.e., if
> the only address you have becomes deprecated, you are still allowed to
> use it. 2462 says you SHOULD NOT use a deprecated address for new
> communication if a preferred address of sufficient scope exists. Thus,
> it still make sense for an implementation to try using a deprecated
> address if their are no other better addresses available.

OK, so I just misread it the first time.

Thanks,
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 Sep 1999 14:53:38 +0200

In your previous mail you wrote:

   >    - X will keep the binding update that it receives from H 
   > in its binding
   >    cache. Note that this is a cache. If the binding update 
   > should get dropped
   >    from the cache, then X will not be able to reach H. (In 
   > the mobility case,
   >    this is OK because H is still reachabile via the home agent.)
   >    
   > => I have already received a comment about this problem. I have to add
   > some statements about a reasonnable refreshing strategy for binding
   > updates (the real mobility uses by default detection of traffic at the
   > mobile end of the tunnel, more important for the real 
   > mobility bindings
   > are only an optimization).
   
   I think it's a big problem. Even it you put in some refreshing strategy,
   it's not clear how that might interact with different caching strategies.
   There will likely be intermittent losses of connectivity.
    
=> perhaps we need a new bit in binding updates because for the real
mobility when connectivity seems to be lost then bindings should
be flushed which is the opposite.
I've put back the IPng list in this discussion, if you are not
familiar with IPv6 mobility skip this.

When a mobile goes from home to visit a loss of a binding is not important
because traffic will come through the tunnel via the home agent.
When a mobile goes from visit to another place (visit or home) then
the old care-of address can be no more usable then a binding update loss
has an impact. If for some reasons all binding updates are lost then
the correspondant will flush the binding (on timeout or because connectivity
seems bad) and use again the tunnel via the home agent.
Then the right action when something can be wrong is to flush bindings,
this behavior is not what we'd like to get for mobility then we need
a way to signal the condition (a bit or something else).

[email-masked]

PS: other issues are correspondent detection and security negociation.