[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]



There is no reason to do this based on my previous mail.
/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com] 
> Sent: Friday, May 09, 2003 4:11 AM
> To: David Conrad
> Cc: multi6@ops.ietf.org
> Subject: Re: GSE IDs [Re: IETF multihoming powder: just add 
> IPv6 and stir]
> 
> 
> David Conrad wrote:
> > 
> > Brian,
> > 
> > On Wednesday, May 7, 2003, at 02:08  AM, Brian E Carpenter wrote:
> > >> Or you simply rewrite the first 48 bits when the packet 
> traverses 
> > >> the border into the destination site with the same value 
> the packet 
> > >> had prior to traversing the border of the source site.
> > > This was not part of any GSE proposal I ever saw,
> > 
> > Different terminology would be helpful.  Of course, this implies my 
> > messages on this topic have been whistling past people for the last 
> > two months.
> > 
> > > and it involves stateful
> > > distribution of mapping information.
> > 
> > Yes.  In one approach, a mapping of a globally unique 48 
> bit value to 
> > a set of other globally unique 48 bit values where that distributed 
> > lookup of that mapping occurs at the source border only.
> > 
> > > A very different beast from GSE,
> > > and it sets off my stateful=bad alarm.
> > 
> > Your alarm must go off continually today,  as the mapping 
> is more or 
> > less equivalent to either the DNS or routing tables, 
> depending on your 
> > point of view.
> 
> Right, and we know that faulty DNS setups cause connectivity 
> glitches on a daily basis - because DNS state is created and 
> managed by every site worthy of the name, and mistakes are 
> inevitable. We also had years of 
> connectivity glitches caused by BGP4 configuration errors - 
> most operators 
> seem to have that figured out now, but it was bad for a 
> while. Introducing 
> a third distributed state mechanism that will be critical for 
> connectivity 
> is indeed a big step. 
> 
>    Brian
> 
>