[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
>
>