On Wed, Oct 24, 2012 at 12:58 PM, heasley <[email protected]> wrote: > > its used as a "TE" knob...
[snip]. given the lack of > TE knobs, a lot of hatred should be expected if its taken away (deprecated > or > "secured"). Just to educate anyone who is not familiar with *why* it is used, I'll explain the most common *how*: Since it has 3 possible values, and is used immediately after as-path-length in the BGP path selection process, it can be treated as a "fractional" as-path-length value (0/3, 1/3, or 2/3) for breaking ties in as-path-length. If two received routes for the same prefix/length have the same as-path-length, and the same ORIGIN attribute, the ORIGIN is effectively ignored. If the ORIGIN attribute differs, then ORIGIN breaks the tie, and no other attributes are compared (only with respect to those two routes, of course). One way I've seen it used, is in an attempt to influence return traffic along the same path as sent traffic, e.g. to achieve non-asymmetric traffic flows. These are helpful in identifying (and avoiding) high latency/loss links not directly under one's control. The places this is most commonly done are: By the originator By the originator's upstream transit provider(s) (or their providers, etc.), who is/are not default-free By the recipients' upstream transit provider(s). By the recipient In the case of the recipient, he/she is clearly free to munge it *after* all BGPSEC validation is done. So only the other three cases need to be taken into consideration. Maybe there should be a way to optionally include attributes to sign & protect? This would be a good candidate. First one to stomp on it and sign it wins. Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
