North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Notes on design of IPv6 BGP multihoming with special subrouteattributes (was - Re: Shim6 vs PI addressing)
On Thu, 2 Mar 2006, Owen DeLong wrote:
I think that is overly pessimistic. I would say that SHIM6 _MAY_
Probably 20 bits or 24 bits rather then 18. It maybe worth it to reserve top 8 bits for some experimental future use.Yes, I am well aware of 32bit ASNs. However, some things to consider: 1. Just because ASNs are 32 bits doesn't mean we'll instantly issue all 4 billion of them. The reality is that we probably only need about 18 bits to express all the ASNs well need for
I thought of something of this sort some time ago but never got aroundthe life of IPv6, but, 32 is the next convenient size and there's really no benefit to going with less than 32. 2. In my current thinking on how to achieve ASN based IDR, we would not need ASNs for every organization that multihomes, only for each organization that provides transit. This would greatly reduce some of the current and future demand for ASNs.
to full proposal on it (maybe somebody else did?). I'm trying to go
through my notes now - maybe it could prove useful if research or
engineering people do indeed want to work on something like that.
My thinking was that its a big waste of memory (in the global bgp table) to announce every IPv6 route in full in particular for cases when its sub-allocation and aggregate is already being announced. As an example lets take some ip block like say A100:1000::/32 that is allocated to an ISP 'A' by RIR. Now lets say that this ISP 'A' (AS1) has a customer who received A100:1000:0010::/48 and later same customer got connection from ISP 'B' (AS2) as well and wants to multihome. For normal BGP that would mean that full route of A100:1000:0010::/48 would appear in BGP and increase its size quite a bit.
But it maybe possible to do limited bgp multi-homing by having such /48 and similar routes included as attributes of the main route, i.e.
A100:1000::/32 route would appear with extended attributes like
Subroutes: 0010/16 (2)
Where "0010/16" indicates subroute as seen within A100:1000::/32 ip block (i.e. netmask here is added to netmask of A100:1000 route to get full netmask on the internet) and "(2)" is an additional ASN that such subroute can also be found through. Now if properly designed, such subroute attribute can be compacted to be around 64 bits extra each (slightly
more if multihoming is through more then one ASN and subblock is smaller size then /16) and 64bits data for each multi-homed customer in BGP appear to me something that we can deal with.
Unfortunately with this design, the issue then becomes how some AS10
(the end-site) knows how to get to AS2 (one way maybe to do ASN routes as part of BGP in addition to ipv4 and ipv6 routes). As well as what to
do if connection from customer to AS1 or from AS1 to internet drops since its AS1 that announces such subroutes as part of its aggregate
and purpose of multi-homing it to let it work without it (this can be
done with AS2 also announcing A100:1000::/32 but with special attribute
indicating its valid only for subroutes and such route should not be
propagated if same ASN also sees primary AS1 direct route).
Another possibility of similar design (kind-of already mentioned above)
is to allow AS2 to announce A100:1000::/32 on the internet as it would
its own route but indicate that it is valid only for specific subroutes and not as an aggregate (in fact in this design AS1 would not even have subroutes in its main route announcement). While this means entire full route on the net, the hope is that if AS1 and AS2 have number of common multi-homed customers, the net would be spared from separate BGP routes for each one and the end-site AS10 would only see something like:
BGP routing table for A1000:1000::/32
9 8 7 6 1
5 4 3 2
Origin IGP, Subroutes-Only
Subroutes: 0010/16 0101/16
So from above if router needs to send data to either A1000:1000:0010::/48
or A100:1000:0101::/48 it would choose 2nd path through peer AS5 as having smaller as-path.
All these approaches (especially second one) however certain problems when
you have to consider route security & authorization (i.e. SIDR/SBGP space)
as its necessary to convey that AS2 is to be allowed to announce A100:1000:
block for specific subroutes. But I think these issues can be worked out
like having AS2 sendscertificate request for subblock to AS1 which it then
signs and gives new certificate authorizing announcement with specific
subblock attribute to AS2.
More general issues with these approaches is obviously that there is no
possibility of PI space as customers that need multi-homing would have to get space from one of its ISPs (well, actually it is still possible to do PI - it is just that multiple ISPs would be expected to announce large
aggregate of the PI block with bunch of subroutes on equal basis).
Anyway, if you have comments or if something like this has already been
discussed and tested, I'd like to hear. Otherwise, hopefully knowing about this design may prove useful if shim6 does not work out.