On Tue, Apr 10, 2012 at 1:57 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. > > > No. You are breaking things. BMP is not ibgp nor it is ebgp ! The station > which works today and get's BGP sessions over BMP will now be useless as > AS_PATH will not be there.
great, so ... bmp can either: 1) be treated as a non-BGPSEC speaker (synthesize on the output to bmp listener) 2) be updated to include the BGPSEC relevant data in payload downstream tools using the BMP stream(s) of course would have to be updated. This doesn't seem like a huge deal though, and certainly is expected. > I assumed you know, but BMP idea is to replay what you are receiving (as > verbatim as implementation allows). sure, so it has to know about new bits/pieces, nothing new here. If you catch larry you might get this change/addition into his final/final version before rfc-editor cuts the rfc. > >> maybe? so far you've not convinced me... you can feel free to keep >> trying though? email is cheap. > > > I am not sure there is point in "convincing". Removing mandatory path > attribute from BGP would be something IDR WG has to formally approve. And it > will be an interesting precedence in any case ;) sure... once things settle out on the SIDR side, I'm positive we'll have this discussion in IDR. You seem to be working through the machinations of 'how do I deploy bgpsec in a network', is that the case? would you be willing to document/presentation-style (or wiki or ...) the process for this? It seems like something other folks are going to want to reference/use/discuss as well, so having a few worked examples would be nice. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
