On Tue, Apr 10, 2012 at 1:47 PM, Christopher Morrow <[email protected] > wrote:
> On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <[email protected]> wrote: > > > All BGP monitoring tools need to be upgraded to now understand BGPSEC > > attribute too. And surprise .. here BMP will not convert it like it will > to > > "legacy" speakers. > > sure, they'd have to do that anyway, or they just are > 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In > other words, tomorrow for them is the same as today, the world keeps > on going round. > > > You may think that if we stuff all "data" in the new attribute and drop > the > > other one everything else will work. This may be so in theory, but it is > > clearly not a case in practice. > > maybe? so far you've not convinced me... you can feel free to keep > trying though? email is cheap. > > Okay, I'll bite... Suppose someone wants to take an existing tool which speaks BGP, and writes out full tables and updates to files. Call it "bgpmon". :-) The obvious thing to do for that tool, would be for it to advertise that it speaks BGPSEC, and record the updates that come from BGPSEC speakers. Clearly, this tool is not a router, nor does it need to do validation. In fact, you *don't* want to validate, since you want to record all updates, *including* invalid updates. The ability to do quick-and-dirty comparisons between BGP-vanilla and BGPSEC data, from archived data, would be significantly hampered if the AS_PATH had to be reconstructed from this data. Duplicate bits should really not be a huge deal. Perhaps, at minimum, there should be a negotiated option on whether or not the AS_PATH is included in updates, on a per-neighbor basis? That would allow both sides to win, and even better, provide some measure of interoperability testing, including possibly passing the opaque attribute through non-believers to far-end systems that want to see *all* the BGPSEC data, even when it has crossed outside of the BGPSEC bubble. In particular, this would be very helpful during the incremental deployment phases, where there are *multiple* islands of BGPSEC. Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
