I think we are chasing our tails around the use of path as an abstraction of the set of peering relationships and PATH as a specific sequence of announcements of a given prefix (I.e., the AS_PATH attribute).
Not that the debate isn't amusing, but sorting out those terms out might allow it to move forward. dougm -- Doug Montgomery Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/21/12 9:10 AM, "Russ White" <[email protected]> wrote: > >>> So, just to ask... Suppose you have this: >>> >>> A---B---C---D >>> | | >>> +---E---+ >>> >>> 1. The existence of the link from B to E is a fact within the topology >>> shown. >> >> nope, it is not. A is a peer of B and E is a peer of B, so there is no >> path between B and E for A's prefixes. sorry charlie. > >I can't even begin to make sense out of this --can you explain? If A/B, >B/E, and E/D are valid peering pairs, then the path exist. If B chooses >not to advertise some route from A to E, that's a local policy decision. > >If you modify the protocol so D can tell B didn't intend to send a >specific set of destinations to E, then you've injected policy into the >protocol. There's no way to escape the conclusion that BGPSEC injects >policy into BGP itself. > >Russ >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
