| This is the plan. We start out with no holes in BGP and we try to
| keep it that way.
Ah, BGP.
Ok, so it seems like there is a 1-1 mapping of TLAs to AS numbers --
after all, why would an AS encompass more than one TLA prefix?
What happens if and when the 8k limit on TLAs is relaxed, because
the number of organizations qualifying for (however this might happen)
a TLA assignment exceeds that number, given that the relaxation might
well take us beyond 16 bits of TLA (I take this as implied by Christian's
earlier comment).
The second half of the question above: why would one split a TLA
across multiple ASes in the default-free zone? For NLA<>TLA, do
you propose to have (possibly floating) static routes be the means
of handling NLRI? That is, we configure default on each operational
connection to the TLA that the NLA connects to (and deconfigure at
each interface when it is not operating), while we configure static
routes to the NLA addresses at the border of the TLA. Yes?
I found no FM to R on this subject.
Will any effort be made to keep the NLA IDs both globally unique
and portable? Or, because TLA+NLA may share the same NLA bit
pattern with another 2nd-level network TLA'+NLA, will 2nd-level
networks who multihome to multiple TLAs do one of:
a/ be "promoted" and become a TLA themselves
b/ carry multiple NLAs, assigned by each TLA they interconnect with
? If (b) do we make the tunnel hack work, or do we make the NAT hack work,
or both, or do we just ignore what to do about losing connectivity
to one or more of the TLAs to which a 2nd-level network is connected?
On the other hand, if the NLA bit patterns _are_ kept globally unique
and portable, how will reachability via one or the other of multiple
TLAs be announced to the global core network?
Sean.
P.S.: Someone should eliminate the apostrophe in the first line of 3.4
of RFC 2374
