"You have to change your server's IP address if you want move your server to other place"
-> It is very natural case, but some customer could think of it will be okey to move if they have C class.
but I have different idea. because the border router of that center is annoucing more greater IP block,
and if customer move to other center with C class, then I have to newly announce that C class at the border router of other center.
and then it is the time my hierachy structure is broken.
To prevent this situation, I'm trying to find some standard material every person would understand and accept.
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
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 184.108.40.206/23 as a PA subpart
of its own space. 220.127.116.11/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 18.104.22.168/8?
Now, assume that customer gets a single link to a different provider B,
whose PI space is 22.214.171.124/8. For multihoming to work, at least two things
start to happen. Both providers A and B need to announce 126.96.36.199/23 to the
rest of the Internet. If only provider B advertised (188.8.131.52/8,
184.108.40.206/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 220.127.116.11/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?