In theory, this would be covered by moving AS279 from the AS macro for MCI to the AS macro for UUnet. In current practice, because AS macros are not widely in use (and aren't in our machine generated aut-num right now), this will have to be coordinated among providers (like you send us a note saying your entire AS has moved). The idea is that this doesn't happen all that often. If it does, the AS macro is a decent way of handling it. Steve
What happens if policy changes for those AS'es?
i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to ro ute through AS701. (*grin*)
How is new policy to be determined, either for new ASes, or for existing ones that drastically change their routing policies?
_k
Elliot,
Ignore the advisory. If AS2 is the origin, we will route traffic for that particular prefix/masklen using the most common policy already in place for routes in AS2.
If the common policy is for us to send traffic destined for AS2 via our peer AS1, we will continue to do so for the new prefix/masklen.
Steve
After this time, AS690 advisories will be ignored. Policy toward routes registered in the IRR will be based solely on origin AS. The origin AS will be expanded to the set of route objects registered for that origin AS; the resulting list of prefixes will be used in generating router configurations, as today.
in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object and list themselves as the origin, and put AS#1 in the advisory. in the new scenario, will ANS now only allow routes coming via the ASN in the ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field to AS#1 so ANS knows where to look for for the routes?
- elliot alby/sprintlink implementation