On Oct 23, 2012, at 11:14 AM, Randy Bush <[email protected]> wrote: > sandy asked so i investigated. > > bgp has an origin atttribute. it looks as if we need to protect it. > > the origin attribute may have three values, > unspecified > igp > egp > supposedly denoting from where the route was injected into bgp. > > jeff haas has a better memory than i, and noted that > > the key is that 'egp' does not mean an abstract egp, but the old egp > protocol which was classful and aggregated. > > if it aggregated, you had to be careful that this did not suddenly hide > things and ignorance thereof could open you up to loops. so the origin > attribute was added. > > but it is in the bgp decision process. it is prettly low down, but > could be used for traffic engineering or other, less nice, influencing > of the decision process.
Yes. And it *is* used for TE purposes in simple places... > > hence, bgpsec should probably should protect it. Not sure I agree with this part -- simply because it can be used in the decision process doesn't automatically mean it needs to be protected. It (and med and IGP cost and routerID) "feel" to me like they are low enough down that they can be (and should be) left alone, to allow operators some flexibility (Yes, Origin is set by the originator, the rest of these things are more about the local network, but I still don't think that this automatically means that it needs to be protected). By allowing folk to turn (ok, stomp all over :-)) the setting of Origin those folk that have networks with more than one AS can influence their inbound, folk who want the ability to chance things further down in the decision process still have that, etc… W > > randy > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > -- She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade) _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
