a different proposal for ipv6 in bgp

[Dimitry Haskin]

Tony,

> 
>  Dimitry Haskin <dhaskin@baynetworks.com> writes:
>   * At 04:53 PM 1/6/97 -0800, Dave Katz wrote:
>   * >It remains unclear to me why it is desirable to couple multiprotocol
>   * >support and the AS number space increase.  The two functions are
>   * >completely orthogonal and as far as I can tell there is no benefit for
>   * >*mandating* that the two changes be made at the same time.
>   * >
>   * >Clearly the multiprotocol stuff could be deployed and become useful
>   * >more quickly than the AS number extension, due to the fact that it
>   * >can be done in a backward compatible, pairwise fashion.
>   * >
>   * I don't believe that this assessment is accurate.  The BGP5 proposal
>   * is as backward compatible (if not more) with BGP4 as the proposed multiprot
>   * ocol 
>   * extension to BGP4.  I.e., v4 routing information exchanged between BGP5
>   * peers can be fully re-advertised via BGP4 and vise versa.  As you might not
>   * ice
>   * we even didn't require to immediately extend AS number space for v4
>   * to keep the v4 related changes to a bare minimum.  To support v6, bgp data
>   * structures need to change any way and v6 has no backward compatibility
>   * issue at this point. Thus it only makes sense to get a larger AS space for
>   * v6 now
>   * to avoid another transition later.
>   * 
> 
> Let's perhaps look at this a little differently. Since widespread
> deployment of BGP4 and the hassle of transition from BGP3 (for those
> of us who went through this, it was certainly not something to do more
> than say a couple of times in your lifetime and in that case we were
> driven by an immediate need) we have actually been able to add several
> new attributes (communities, reflection, etc) to keep enhancing
> inter-domain routing capabilities (all in use today) with very little
> pain.

We definitely not proposing a transition of the grand-scale of moving
from the classfull to classless routing paradigm.  I can assure you that
what we're proposing is of a much smaller scale, practically no scale at all.
And our intention was to make it even more extensible than BGP4.

>The reason we've been able to do this is becuase we essentially
> haven't messed with the underpinnings of the protocol itself.

Neither did we.

> The operational factors in doing this are much greater than perhaps many
> folks realize (ISPs tell me different if you think I'm
> overstating). In your proposal, before I can get benefit of the pain I
> need to move I have the entrie Internet moved over to BGP5.

This is definitely an overstatement.

> I understand I can use it for multiprotocol on a pairwise basis
> providing I dont touch the AS space but this doesn't seem like too
> much of a win when I can add attributes to the exisiting BGP4 protocol
> and start using BGP for multi-protocol interdomain support in an
> understood and well-practiced operational way.

This is a win because we don't have to drag 2-byte ASN into IPv6.
There is enough discomfort with the 2-byte ASN to make me belive that
dragging 2-byte ASN into v6 as a bad idea. And the most important it
is _not_ necessary.  Is it v6 that all this multiprotocol support
is really about?

And, if you want, you can use the option of gradually extending ASN for
v4 too.  For some, probably long,  period simple mapping of zero-extended
4-byte ASN into 2-byte ASN used by BGP4 will ensure backward compatibility
with BGP4.

> 
>   * >The deployment considerations for multiprotocol support are far less
>   * >onerous than the AS number stuff.
>   * >
>   * Care elaborate (in light of the BGP5 proposal)? 
>   *  
> See above.

See above.

> 
> If you buy into my ease of deployment point above [and of course you
> might not] let's look at where we are in terms of AS space as this is
> other factor driving the current discussuion.  Since I've started the
> CIDR report I produce I've also been tracking the activity of ASes in the
> global routing system as seen in BGP by a well connected router. The
> interesting trend you see is the growth of ASes in the global routing
> system is essentially linear. Whilst my data source is quite small (see
> http://www.remplyees.org/~tbates/cidr.as.plot.html) this seems to be
> growing at an average rate of 3 ASes per day. The linear growth if
> further backed in "An analysis of Internet Inter-Domain Topology and
> Route Stability" by Ramesh Govindan and Anoop Reddy from USC/ISI.
> 
> If we use this growth rate and look at a couple of scenarios:
> 
> Best Case 
> ---------
> Assuming we have 65000 (not including Private ASes) ASes and
> accounting for the 1937 ASes already in the system (this also assumes
> we could re-use ones pre-allocated and not currently being used which
> is probably over optimistic) we have 63063 ASes to play with resulting
> in :
> 
>         63063/3 = 21021 Days
>         21021/365 = 57 Years before we run out.
> 
> Worst Case
> ----------
> 
> If we assume 15535 ASes will in fact be wasted (private space,
> early/bad allocations before RFC1930, some ISPs getting as AS 
> for the wrong reason) we still end up with.
> 
>         (50000-1937)/3/365 = 43.8 years
> 
> Now you could argue that this doesn't take into account the increasing
> trend towards mutlihoming (not currently shown in the AS growth either
> but anyway ;-)). However, there are a number of things to help with
> this approach. 
> 
> 1. Improving use of private AS space. ISP router should be able to
>    override customer's AS with a preconfigured number. ISP router
>    shouldn't propagate a route to a customer router if the route includes
>    AS of the customer (this AS is preconfigured on the ISP router).
> 
> 2. Use RIPv2 (instead of BGP) - doesn't require AS number at all.
> 
> 3. Use single globally unique AS number (draft-stewart-bgp-without-as-00.txt)
>

None of that will be necessary for v6 if we use a larger ASN space there.
 
> So with this in mind do we really want to tackle the AS number issue
> right now at the risk of the operational impact ?

You still didn't convince me that there is a significant operational impact
with the BGP5 proposal.  If you afraid to extend ASN for v4, we don't force
you to do so. But we want a larger ASN space for v6.  Would you agree that
there is a zero operational impact for v6 at this point? If it not for v6 we,
most probable, would be looking in extending BGP-4, don't we?


> If the answer is yes
> (which I must abmit seems hard to see from my viewpoint) then we
> better make sure we look at all aspects before spinning the protocol
> again wouldn't you agree ?
>
Sure.
> 		--Tony
Dimitry