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

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

I think it is good to agree to disagree and move on 1000% agree.  In fact we would all get more done and move on if we could all do this and simply admit it.

I agree completely this is a real good work item for new v6ops and could even suggest tools for use within 6to4 as BCP.

/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Wednesday, September 11, 2002 11:01 AM
> To: Bound, Jim
> Cc: Hesham Soliman (EAB); Margaret Wasserman; v6ops@ops.ietf.org
> Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops)
> 
> 
> We'll have to agree to disagree. I think that text is necessary and 
> sufficient for a standard; but undoubtedly a BCP is needed as 
> well, to 
> cover the scenarios and examples. Such a BCP would be a fine work
> product of an operations WG, I think.
> 
>     Brian
> 
> "Bound, Jim" wrote:
> > 
> > Brian,
> > 
> > from rfc 3056: The below is punting.  It did not give 
> examples, it does not discuss ramifications of policy, it 
> does not have applicability statement it just says BGP+ is 
> being used as standard.  Based on what we have to do today to 
> get through the IESG loop with new specs this is punting.  
> Also Sowmini and I beat on this and wanted diagrams but we 
> gave up.  It also affects the relay routers too if they 
> happen to be egress routers.
> > 
> > So it did punt.
> > 
> > /jim
> > 
> > 5.2.2.1. BGP4+ not used
> > 
> >    If BGP4+ is not deployed in the 6to4 exterior routing 
> domain (option
> >    2.1 of Section 5.2), the relay router will be configured 
> to accept
> >    and relay all IPv6 traffic only from its client 6to4 sites.  Each
> >    6to4 router served by the relay router will be configured with a
> >    default IPv6 route to the relay router (for example, 
> Site A's default
> >    IPv6 route ::/0 would point to the relay router's address under
> >    prefix 2002:09fe:fdfc::/48).
> > 
> > 5.2.2.2. BGP4+ used
> > 
> >    If BGP4+ is deployed in the 6to4 exterior routing domain 
> (option 2.2
> >    of Section 5.2), the relay router advertises IPv6 native routing
> >    prefixes on its 6to4 pseudo-interface, peering only with the 6to4
> >    routers that it serves.  (An alternative is that these 
> routes could
> >    be advertised along with IPv4 routes using BGP4 over IPv4, rather
> >    than by running a separate BGP4+ session.)  The specific routes
> >    advertised depend on applicable routing policy, but they must be
> >    chosen from among those reachable through the relay 
> router's native
> >    IPv6 interface.  In the simplest case, a default route 
> to the whole
> >    IPv6 address space could be advertised.  When multiple 
> relay routers
> >    are in use, more specific routing prefixes would be advertised
> >    according to the desired routing policy.  The usage of BGP4+ is
> >    completely standard so is not discussed further in this document.
> > 
> > > -----Original Message-----
> > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> > > Sent: Wednesday, September 11, 2002 5:16 AM
> > > To: Bound, Jim
> > > Cc: Hesham Soliman (EAB); Margaret Wasserman; v6ops@ops.ietf.org
> > > Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops)
> > >
> > >
> > > 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
> > > > >
> > >
>