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

["Bound, Jim" <Jim.Bound@hp.com>]

ALso this is just one infitesimal piece to multi6 to solve "keeping the
orginal node IP delivery address on the LAN" (using old standard terms
on purpose).  Possibly what we have to do for multi6 is break the
problem area into multiple pieces that need resolution instead of trying
to solve it as huge glob all at once and part of what has been holding
us up.

For example why not agree on what loc is equivalent to and how many bits
and ID for semantics?  Then go to next step.  If it breaks we
reevaluate.

That way bright people here can be working on specific tasks.  In fact
different bright people can go off and work on different aspects.

Then each with solution can look at those parts for their favorite
solution HIP, MHAP, MIPv6-LIKE.

/jim

> -----Original Message-----
> From: Bound, Jim 
> Sent: Friday, May 09, 2003 9:47 AM
> To: Brian E Carpenter; Iljitsch van Beijnum
> Cc: multi6@ops.ietf.org
> Subject: RE: GSE IDs [Re: IETF multihoming powder: just add 
> IPv6 and stir]
> 
> 
> I went to an industry session yesterday in New England that 
> discussed blades, switches, 10gbE and beyond.  The IPv6 PMTU 
> is large and capable. I believe adding 128bits at original 
> node idea to a DST, EXT option will not kill the Internet or 
> fast path for any ASICs I am looking at now (not for routing 
> but host IP / IPsec offload engines for prototype and 
> research on day job).  Just as note.  Also routing header is 
> not a good idea that was just off the top of the head.  EXT 
> or DST option would the way to go and be transparent to 
> routers which is one of my goals.
> 
> /jim
> 
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> > Sent: Friday, May 09, 2003 9:09 AM
> > To: Iljitsch van Beijnum
> > Cc: Bound, Jim; multi6@ops.ietf.org
> > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add 
> > IPv6 and stir]
> > 
> > 
> > Iljitsch van Beijnum wrote:
> > > ... NAT shows that it is
> > > possible to build middleboxes that keep lots of state.
> > 
> > and the failure modes associated with NATs show why
> > this is a really bad idea. But even NATs keep that state
> > reasonably local; it doesn't have to be known by magic to an 
> > anti-NAT at the other end.
> > 
> > Iljitsch, the big hole in your -00 draft is that is doesn't at all 
> > discuss the magic needed to distribute mapping state and keep it 
> > fresh. As I think I already said, this is why we never pursued the 
> > map-and-encap proposal some years ago- it's not a side issue, it's 
> > *the* issue in this class of solutions, and it is the fundamental 
> > difference from 8+8/GSE.
> > 
> > I believe MHAP does discuss this question. And as Jim said,
> > there are stateless solutions, but that means adding bits to 
> > the packet.
> > 
> >   Brian
> > 
> 
>