Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
On Thu, Dec 16, 2010 at 09:03:04AM -0800, john heasley wrote: Thu, Dec 16, 2010 at 04:35:09PM +, Jeffrey Haas: SNMP is *not* a good tool for monitoring routing state. It's fine for monitoring peer counters and monitoring specific prefixes using standard polling techniques. Please repeat this to yourselves every time you think of SNMP and routing. I think my rant at the OPS and routing area open meetings a few IETFs back convinced the relevant people that we should never try to push for such things in SNMP again. But this does mean that if you care about getting such state with a clean presentation layer of some sort (i.e. no screen scraping), spend some cycles in places like netconf/netmod. Contribute. And then convince your vendors to implement. :-) -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
On Dec 15, 2010, at 6:16 PM, Nick Hilliard wrote: 1. please encode 1970-epoch timestamps as 64 bits, not 32. 32 bits will break before I retire. This is not out of the question, but keeping in mind that there's already implementation of the currently specified format, what is the value of making an incompatible change in order to avoid a wrap in 2106? I'd think that given 96 years to work on it and a grasp of modular arithmetic, it may be possible to work up BMP listeners that deal gracefully with the wrap. Further feedback from the WG on this point would be welcome. Also, out of curiosity, do you really expect to still be working in 2106? 2. ASCII. Sigh. Colleagues keep threatening to educate me about text internationalization but it hasn't happened yet. If someone would care to contribute the least-onerous possible revision that would make the spec internationally correct, that would be welcome. 3. maybe TLS/SSL instead of ipsec? It's not that I loathe ipsec (I don't); it's just that ssl is much easier to implement, as there are well understood client system APIs for it. IPSec is exemplary, not normative. TLS/SSL is another example, we can mention it and list in the Informative References too if folks feel that would be helpful. 4. address encoding: would it not be wise from an implementation point of view to include the protocol number near the address fields, on the basis that ipv4 == len(4) and ipv6 == len(16) is, well, a bit hacky? What if there's some other protocol in future which might want to use BMP? I won't argue it's not a bit hacky but it's a fairly common idiom. As a practical matter, BMP is pretty tightly bound to BGP and BGP is only specified over v4 and v6. I won't argue that generality isn't good in principle though, all things being equal. Feedback from the WG on this point would also be welcome, again bearing in mind that there's already running code. Regards, --John ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
On Wed, Dec 15, 2010 at 3:26 PM, Robert Raszuk ras...@cisco.com wrote: John at all, Title : BGP Monitoring Protocol Author(s) : J. Scudder, et al. Filename : draft-ietf-grow-bmp-05.txt Pages : 16 Date : 2010-12-15 If I remember correctly the fundamental reason for bmp was to provide a very simple mechanism for replaying content of received updates from the peers as well as provide some form of signaling reg their state transition. That goal was great. Unfortunately version -01 and above moved away from this and simplified the requirement to reply/send content of Adj_RIB_In instead of those coming updates from the peers. It allowed an implementation to reconstruct updates, rather than replicate them. So we are effectively loosing the most crucial part of the original proposal as we no longer be able to pass to some observatory linux station those prefixes which were dropped on inbound or worse any potential malformed updates or attributes if they were not stored in the RIB_In. I disagree. The most crucial part of the proposal is to get the contents of Adj_RIB_In from the router to a monitoring station, without the filter of best path selection that occurs when you use BGP peering as a means to monitor what the router sees (and bgp-add-paths doesn't accomplish this, either). The corner cases of malformed updates and filtered updates simply aren't interesting for the application that this protocol was designed to enable - centralized analysis of the whole of an autonomous system's Adj_RIB_In. I think it defeats a lot of use cases. Perhaps this subtle difference should be discussed more before we proceed any further with this document. This was discussed before, if I recall correctly. BMP is proposed to do one job well, and that's to get the collected Adj_RIB_In out, globally, to where it can be processed by real computers. Stephen ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
Thu, Dec 16, 2010 at 06:27:54PM -0800, John Scudder: On Dec 16, 2010, at 8:08 PM, Stephen Stuart wrote: I think it defeats a lot of use cases. Perhaps this subtle difference should be discussed more before we proceed any further with this document. This was discussed before, if I recall correctly. That's correct. In fact because of the divergence between -00 and -01, I took pains to make this clear when presenting -01, including at NANOG and GROW and probably other places. Those interested in the history should be able to find the slides easily enough. why does this matter? sure, adj-rib-in is MUST, but can that not be configurable which is (are) exported? ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
