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

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

I think this is formally called a spriral engineering process using the
E letter in IETF :-)

/jim

> -----Original Message-----
> From: Bound, Jim 
> Sent: Friday, May 09, 2003 10:10 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]
> 
> 
> 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
> > > 
> > 
> > 
> 
>