On Mon, 21 Feb 2011, Shane Amante wrote: | |But, who is certifying what are legitimate vs. illegitimate AS_PATH's |when the AS_PATH is greater than 2? | |IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing |transit from two upstream providers: AS_B and AS_C. In that case, the |originating AS, AS_A, certainly has 'authority' on who (or, what set of |AS'es) should be providing it with transit. And, I can see the origin |AS, AS_A, having something analogous to an IRR 'aut-num' object to tell |the world what AS'es it is exporting/importing routes/AS'es to/from. |Operationally, this is already done today (for those that use IRR aut-num |objects, at least). I get it. If this is where we draw a line in the |sand that we want SIDR work to go, but no farther (at least for now), |then OK. (However, I'm still not sure if REQ #4.1 in |draft-ymbk-bgpsec-reqs-00 is intended to address an origin ASN -> transit |provider's AS_PATH relationship reqm't or is restating what the concept |of ROA's do today. Can someone clarify?) | | |However, the impression I'm getting is that folks want SIDR to go a step |beyond that. For example, AS_B and AS_C announce AS_A on to their |upstreams/peers -- and, this is where I don't get it. Let's use just the |case of transit provider AS_B. Let's say he announces AS_A onto AS_X, |AS_Y and AS_Z, so you have an AS_PATH that looks like the following: |AS_X AS_B AS_A |AS_Y AS_B AS_A |AS_Z AS_B AS_A | |At this point: |a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z |... and, just as importantly, /further beyond AS_X, Y and Z/. |b) Just as importantly, there is no IANA or RIR -- currently! -- that |certifies the contractual linkage between AS_B and AS_X, Y and Z. | |From a contractual PoV, AS_A has very little to do with _who_, beyond |his directly connected transit providers/peers (AS_B and AS_C in this |example), his routes are announced to. Instead, AS_B is contractually |obligated to announce, or not announce, AS_A's routes based on whether |AS_B's connected AS'es are peers or transit providers.[1] (Yes, there |are exceptions like AS_A tagging routes with "NO_EXPORT", but |operationally those are most likely an exception, IMO, intended to withhold more-specifics ... not 'general' reachability/connectedness). |
In your example where AS_A buys transit from AS_B and AS_B buy transit / Peers with AS_X, AS)Y, and AS_Z... When AS_B announces AS_A's prefix to its upstreams, it is asserting two things: 1. AS_B learned the prefix from AS_A, choose it as best, and does not have policy to limit the distribution of the route. 2. That network represented as AS_B has the right to use the ASN value AS_B. -- The RIRs validate this Likewise when AS_Z propagates the prefix it makes the same claim, that it has learned the route from AS_B and that it as a network has the right to us AS_Z. __Jason _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
