On Wed, Mar 21, 2012 at 10:08 AM, Russ White <[email protected]> wrote: > >>>>> The point is you've gone beyond the existence of the path here to the >>>>> rightful use of the path --and that is policy. >>> >>>> don't think so. >>> >>> Yes, you have. >>> >>> Because you've insisted on making the solution work per prefix, you've >>> moved the problem out of the realm of path validation and into the realm >>> of per prefix policy. Paths don't exist per prefix. Paths either exist >>> or don't. Only policies can tell you whether or not a particular path is >>> available for a particular prefix. >> >> clearly there's something I'm missing... if we remove the ideas of >> SIDR form the table, how does your picture change? how does the >> outcome change? it SEEMS (to me) that the situation is exactly the >> same... there's no idea of policy in protocol, there is only bgp, and >> the local decision by B to NOT send a route to E. > > But D has no way of knowing this in band without SIDR. With SIDR, it's a > matter of looking at the signatures --by the design specs of SIDR
no, you never sent anything of this route to E so E never had anything to pass along to C and then to D ... knowledge of this path is not there, in both the SIDR and non-SIDR cases. All D knows in both SIDR and non-SIDR cases is: "Look at that, a path through C to B to A, joy!" In the SIDR case, assuming full secure path along from A -> B -> C -> D, D sees: "Hey lookie! a 'signed' path from C to B to A!" The conversation about E never happens, because .... D has no information about E. > itself. When you provide information about who should be advertising to > whom across multiple hops, rather than who is connected to whom, then where is this information? about 'advertising' ? there's no concept in SIDR of 'you advertise to ..' or 'you are supposed to advertise to X'. > you've moved from existence proofs to policy implementation. no, again this isn't the case. Now I think i'm not the confused one... -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
