Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops)

[Brian E Carpenter <brian@hursley.ibm.com>]

I don't agree that RFC 3056 punts on BGP. It's quite explicit about
how relays should use BGP4+. 

   Brian

"Bound, Jim" wrote:
> 
> Brian,
> 
> That is not what should happen.  And we may need this within V6ops per Hesham's many explanations.  Also 6to4 punts on BGP and it could be we need this as adjunct for 6to4 and we should at least look at this in V6ops.
> 
> I also came to the same conclusion of the serendipity of 6to4 in these times.  6to4 would potentially be dead in V6ops too if it did not have and RFC number.
> 
> And lastly I think all transition work that does not fit with V6ops requires its own focus not within the routing area.  What Hesham asks for is required TODAY not tomorrow.  We need possibly the "advanced transition working group" but I have not given up on V6ops either and we will see at the Interim meeting.
> 
> regards,
> /jim
> 
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> > Sent: Sunday, September 08, 2002 10:27 AM
> > To: Hesham Soliman (EAB)
> > Cc: 'Margaret Wasserman '; 'v6ops@ops.ietf.org ';
> > 'ngtrans@sunroof.eng.sun.com '
> > Subject: (ngtrans) Re: WG Review: IPv6 Operations (v6ops)
> >
> >
> > "Hesham Soliman (EAB)" wrote:
> > ...
> > > Let me give you an example, if
> > > 6to4 was written now, it would have suffered the same
> > > destiny as ISATAP or BGP-based tunnelling. But because
> > > it was written a long time ago, it is actually an
> > > RFC. I'm not sure that 6to4 is a better solution
> > > for inter-domain tunnelling than BGP-based tunnels.
> >
> > I think the historical fact is that the BGP-based tunneling
> > proposal emerged later than 6to4 *because* 6to4 talks quite a
> > bit about using BGP to make 6to4 work properly in an IDR
> > context. And of course BGP will work with other methods of
> > prefix assignment too.
> >
> > If it isn't in the v6ops charter, just develop it as an
> > individual submission to the routing area.
> >
> >    Brian
> >