On Sun, Mar 11, 2012 at 5:47 PM, Jeffrey Haas <[email protected]> wrote:
> Brian, > > On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote: > > Greetings, SIDR folks, > > > > Here is the notice on the ID for the route leak "requirements" document. > > I am likely misunderstanding something in this document, but my > interpretation of it is that routes are always colored based on link role. > > This is correct. This is an extension of common operational mechanisms, where ISPs frequently color route internally. The distinction is, this coloring would be universal end-to-end, at least where contiguous areas using the mechanism exist. The down-side is, it is nearly impossible to bridge gaps where the mechanisms are not used. > Consider some prefix, P, sent from AS 1 to AS 2 on two different links. > Link 1 is primarily used for peering traffic. Link 2 is used for transit > traffic. If I'm understanding the draft properly, routes received on Link > 1 > should not be propagated to AS 3 even though it's the same prefix (and path > attribute set) as P received on Link 2. Is that correct? > Correct. This is normally the case anyway, since routes can only be advertised to AS3 if they are selected as "best". This means that for transit to function, the customer side of the transit link must be preferred over the peering link, in one direction. Typically, in combined transit+peering relationships, the benefit is not having the transit link used for "on-net" routes of AS 2. And typically, the peering link is "settlement-free", so this reduces the costs for AS 1. Having the choice of link being determined by source address, is "policy routing", which tends not to be supported at the hardware level. The announcements at the inter-AS level (based on color) is independent on the handling of routing and forwarding at the intra-AS level. Coloring announcements based on link type, and restricting route propagation based on color, does not preclude internal policy routing. (This scenario was one that was explicitly analyzed in developing the three documents.) > > -- Jeff > > Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
