Subject: RE: Session Stability (was multi-homing vs route aggregation)

From: [email-masked]
Date: Wed, 28 Jul 1999 09:33:20 +0100

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, July 28, 1999 4:01 AM
> To:	Joe Abley
> Cc:	[email-masked]
> Subject:	Re: Session Stability (was multi-homing vs route
> aggregation) 
> 
	....

> >Under your draft, a failure of this kind would still require
> >renumbering at the edge of the network, and special treatment for
> >established sessions (if they were to persist, which I would suggest
> >probably ought to be documented as a requirement).
> 
> 	For newly established sessions a sentence in Observation section
> 	may help (setting preferred lifetime of unreachable prefix to 0).
> 
> 
	This part of the draft is a VERY condense version of a longer
discussion I had with Itojun offline about **combining RFC2260 with Router
Renumbering (RR)**. I do not think that addresses Joe's concern but read on
to see what it can do for you.

	Here is summary of the discussion:

	With RFC2260 technique alone when one  of the links fails (say
ISP-BR-B <-> E-BR-A) all incoming traffic from ISP-B will go through the
secondary path (tunnel) ISP-BR-B -> ISP-BR-A -> E-BR-A. Now for existing TCP
connections this is fair enough and better than loosing the connection
altogether. For NEW connections, however, it would be better to avoid using
source address from prefix ISP-B and thus avoid tunnelling on the way back.
RR could deprecate prefix ISP-B and make preferred prefix ISP-A for all new
connections. This way all new connection would go through ISP-A and not
through the tunnel.

	I passed this through Matt Crawford and at least in principle he
considered the use of RR for deprecating prefixes reasonable as long as one
plays with preferred lifetimes and not valid lifetimes.

	Now this only makes sense if the link to ISP-B goes done for some
time and not just few seconds since this could create a bit of a problem?
Matt seamed reasonably happy that this could be done successfully but we can
get into details latter

	Another (probably *extreme* and I only put it here to check
possibilities!) use of RR would be the following:

	Say the RFC2260 scheme is *not* possible (because ISPs do not
cooperate or whatever). One could think of using RR ONLY (without tunnels)
to go some way towards dealing with the problem of link failure. 

	        (ISP A)                         (ISP B)

	        ISP-BR-A                       ISP-BR-B
	            |                             |
	            |Primary link                 |
	            |                             |
	        +---|-----------------------------|--+
	        | E-BR-A                      E-BR-B |
	        |                                    |
	        | Pref-A     <---------->     Pref-B |
	        +------------------------------------+

	To take the example in Itojun's draft say we have the above
connectivity. Also say that all hosts make addresses out of both prefixes
ISP-A and ISP-B. Normally they choose source address based on 'normal'
address selection mechanisms. Say that link to/from ISP-B breaks. All
existing connections using source address with prefix ISP-B will not have
return path anymore. E-BR-B initiates RR cycle deprecating prefix ISP-B.
Source address selection rules take this into account and thus, all new
connections use source address with prefix ISP-A. If the link to ISP-A also
fails, E-BR-A deprecates prefix ISP-A and thus, all new connections can only
use site local addresses and they are not loosing their time trying to
communicate outside the site. Again this is probably very extreme us of RR
and will result in loss of existing connections. 

	As an aside:
	I am not an expert in RR but here is how one can deprecate a prefix
using it if say the link to ISP-B (with Prefix B) goes down.

IPv6 Header
       Next Header = 58 (ICMPv6)
       Source Address = (Management Station)
       Destination Address = FF05::2 (All Routers, site-local scope)

ICMPv6/RR Header
       Type = 138 (Router Renumbering), Code = 0 (Command)
       Flags = 60 hex (R, A)

  First (and only) PCO:
       Match-Prefix Part
           OpCode = 2 (CHANGE)
           OpLength = 7 (reflects 1 Use-Prefix Parts - 2N+3)
           Ordinal = 0 (arbitrary)
           MatchLen = 48
           MatchPrefix = Pref-B/48 prefix

       First Use-Prefix Part
           UseLen = 0
           KeepLen = 64 (this retains the old prefix value intact)
           FlagMask = 0 (copy RA flags from previous) , RAFlags = 0
(initialise  L&A flags in RA)
           Valid Lifetime = 7200 seconds (2 hours)
           Preferred Lifetime = 0 seconds   <------Deprecation!
           V flag = 1, P flag = 1
	           UsePrefix = 0::0

	George
--------------------------------------------------------------------
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]
--------------------------------------------------------------------