I may not completely understand your concerns, especially about customers
moving. I would, however, strongly encouraging not using the terms A,B or
C in NANOG discussions; I've found they lead to assumptions based on
obsolete ideas.
Let's assume an enterprise has had one transit provider, who is in the
default-free zone. Working together, the customer and provider agreed the
customer needed a /23, and the provider assigns 1.0.0.0/23 as a PA subpart
of its own space. 1.0.0.0/8. Using RFC 1998 techniques, for load sharing
at four POPs of that same provider, that customer then announces, at each
POP, a /25 reflecting the /25 used for machines in the local area of that
POP, but also announces the /23. With a single provider, the RFC1998
method applies, and the routes announced are tagged with NO-EXPORT. As
long as the enterprise is not multihomed, its more-specifics will be
handled properly by provider A's announcement of 1.0.0.0/8?
Now, assume that customer gets a single link to a different provider B,
whose PI space is 2.0.0.0/8. For multihoming to work, at least two things
start to happen. Both providers A and B need to announce 1.0.0.0/23 to the
rest of the Internet. If only provider B advertised (2.0.0.0/8,
1.0.0.0/23) to the rest of the internet, all traffic to the enterprise
would come through provider B, because it announces a more-specific. For
the traffic to work, BOTH A and B have to announce 1.0.0.0/23, so other
providers, with full routes, spread load to the two providers.
The enterprise can still announce both /23 and /25 to Provider A, with
NO-EXPORT on the /25's, because Provider A can make use of the /25 to
better manage traffic to its POPs. Administratively, Providers A and B
have to agree to Provider B advertising a piece of Provider A's space.
Am I answering the question you are asking?
��ġ�� wrote: