On Sun, Mar 11, 2012 at 6:00 PM, Jakob Heitz <[email protected]>wrote:
> The essence IMO:
>
> If A sends a packet to B,
> then A must trust A's provider and B's provider
> and by extension, their providers and so on.
>
> A does not trust other customers of those providers
> and does not want his packet transiting any of them.
>
> Now, design the routing to make that happen.
>
>
Thanks, that is a correct summation of what my documents are intended to do.
Link coloring identifies route leaks. Even if the enhancements to not
prevent intermediaries from propagation of route leaks, they make it
possible to identify route leaks.
However, without strong-ish enforcement for stopping propagation of route
leaks, non-leak paths may be suppressed (because only locally-selected
"best" paths get announced).
So, while it may mean a semantic tightening of the notion of "local policy
can do anything", the fact that changing link types (which in turn changes
link coloring) can accomplish everything that "leaks" can do, means there
isn't a strong case for adopting the "opt-in" mentality.
In other words, adding anti-leak techniques to the protocol spec, does this
("make that happen").
Brian
> --
> Jakob Heitz.
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Jeffrey Haas
> Sent: Sunday, March 11, 2012 2:47 PM
> To: Brian Dickson
> Cc: sidr wg list
> Subject: Re: [sidr] Fwd: New Version Notification for
> draft-dickson-sidr-route-leak-reqts-02.txt
>
> 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.
>
> 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?
>
> -- Jeff
>
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
