Hi Robert,
On Nov 10, 2005, at 8:14 PM, Robert Raszuk wrote:
Hi Shane,
Ok so let me ask you and others about scaling principle of this
approach. I think this is brilliant idea for ad-hoc session
monitoring. I would fully support it.
Now looking at some comments made during GROW meeting .. some folks
already go over the board and intend to use it for full scale
session monitoring with possible feedback.
I wasn't able to attend the GROW meeting this time, and unfortunately
the minutes from the meeting don't reflect this concern.
Nonetheless, I don't see the value in using BMP for "possible
feedback," (although I'm sure some route optimization vendors
might). IMO, I think BMP should be scoped as a "one-way, monitoring-
only" protocol. If one wants feedback, then use BGP (or, scripts --
blech) -- of course, one has to be *very* careful not to engineer too
tight of a feedback loop between BMP and BGP, but that's something
that's outside the scope of BMP.
Imagine you have few hundreds of ABRS each few hundreds of EBGP
sesions. Are you going to bridge all of them to a single management
station ???
No, but what I would like to see, at a minimum, ~6 peering routers
bridged to a single monitoring station. However, it would be ideal
if I could have a few dozen routers (at most, < 40) bridged to a
single monitoring station. Presuming I stagger start-up of BMP
sessions to such a large # of routers, during a full reboot of the
monitoring station, I assume a reasonably fast box should be able to
keep up with continuous updates flowing in under steady state and
some operational changes? However, if that's unrealistic, CPU's are
relatively cheap so maybe I have to throw a monitoring box per dozen
routers ... which isn't that expensive.
What problem are we solving ? Isn't this like Chandra Appana asked
during the meeting some issues about implementation defficiencies
to be addressed via a huge overlay ? Should we not fix this or
maybe even perhaps improve BGP itself if something fundamental
elements are missing ?
I'm not sure of the context of this question, but the only value I
see in BMP is monitoring only.
Next thing ... who is going to support full BGP code on the
managemnt station .. zebra ? I strongly doubt it. And clearly it is
needed to parse the latest BGP capabilites, new AFI/SAFIs or even
new attributes.
Well, if open source guys don't develop it, I'm sure there are a
handful of commercial vendors who would easily step in. At the
moment, though, I see the most value in monitoring IPv4 (and,
eventually IPv6), which should be possible in a straightforward
manner with zebra/quagga/etc.
-shane
So before we all jump at support for it - I would recommend to step
back and see what exact technical problem are we solving here ?
Perhaps this is indeed the best solution ... But I would like to
see this a bit deeper analyzed ...
Cheers,
R.
I support this draft becoming a WG draft.
It should be noted that this protocol would be useful not only to
researchers, but also potentially to [some] operators that are
looking for ways to monitor paths, for various troubleshooting
reasons, in a [relatively] lightweight fashion.
Also, I'm curious as to why TCP-MD5 isn't mentioned for use as an
authenticated transport of BMP in the Security Considerations
section, (since TCP-MD5 is already widely implemented and deployed
in routers)? For some environments, e.g.: Intra-AS, TCP-MD5 is
sufficient, since its the de facto transport anyway. OTOH, I'm
not opposed if folks think IPSec is a better answer because it can
provide authentication, encryption or both simultaneously,
(presumably, because BMP is more likely to be run over untrusted,
e.g.: Inter-AS, paths).
-shane
David Meyer wrote:
Folks,
At the GROW meeting this week we took away an action item
to ask the list to please read draft-scudder-bmp-00.txt
and let us know whether you feel this draft should be
adopted. Please let us know your opinion on this.
Thanks,
Geoff & Dave
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/
