I think this question is more about what step in the route selection process (rfc 4271, 9.1.2.2) at which to consider the verification state.
I would answer: nowhere. The verification state should be used as an input to the policy. For example, something for a route-map to match on. The policy would then set another attribute, such as the LOCAL_PREF or deny the path altogether. It may also set a cost community as described in draft-ietf-idr-custom-decision. This resulting attribute would then be used in the route selection process as normal. Exactly how the verification state is used would be up to the network operator. By default, it would not be considered at all. -- Jakob Heitz. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Christopher Morrow Sent: Thursday, March 22, 2012 6:26 PM To: [email protected] Cc: [email protected] list Subject: Re: [sidr] Signed vs unsgned and bgp best path decision On Thu, Mar 22, 2012 at 7:28 PM, Robert Raszuk <[email protected]> wrote: > By chaos I meant complete autonomous selection of what paths are preferred > to be chosen as best on an AS by AS basis. In the case of mixed SIGNED and how is the above any different that what happens today? (inside a single ASN, each router decides what it thinks is 'best', hopefully with a coordinated policy across all devices, but ... that is not guaranteed!) > UNSIGNED paths being consider in this _local_ decision as you stated it > seems to me just like it is the case with bad uncorrelated policies more > harm can be accomplished then good. sure... should someone say: "ACHTUNG!! OPENZ PEEPERZ!! USE THE SAME POLICY ON ALL DEVICES!!" ? I think, I thought, I hope that the above message is (perhaps less comically) stated to all network engineers when they graduate and get their striped hats... (so thus NOT a required statement in an RFC-like document) -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
