> i don't think the case you outline is one of actually telling the > remote-as that the path doesn't exist because of policy. the /fact of > policy/ can be inferred, and I outlined 3 (or more) places you could > infer at D that there was some policy decision happening. I don't > think it's at all clear that you can determine where that policy > removed the path though.
If the advertisement is passed on by the intermediate AS (in this case, E), then you're telling the remote AS that path shouldn't exist --this is carrying policy within the protocol. > I suppose: "So what if this is used for no-export" or "so what if this > is used to ignore no-export" ? The signatures are there so you can > say: "The NLRI I see travelled along the ASPATH shown in the > announcement." > > The policy in place isn't relevant to that... or I don't see that it's > relevant. I do --because we're sneaking policy into BGP under the cover of path security. Again, it would be much simpler to break the problem into two pieces, publicly work out which policies need to be enforced, work out what hiding needs to be done, and then work out a solution to those problems. Hiding one complex problem within another is never a good idea over the long term. For instance, because of the WG's insistence on solving a policy problem in a way that can be hidden, while insisting on not calling that problem a policy problem, we've ended up with a solution that is not deployable and doesn't solve a basic AS Path problem. This is, in my experience, exactly what happens when you don't start with a well thought out set of definitions and categories. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
