On Thu, Dec 16, 2010 at 6:38 PM, john heasley wrote:
> 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
Hi,
I would like to issue last call for draft-ietf-grow-unique-origin-as-00. We
will close last call Jan 2nd 2011.
Please review the draft and provide any last comments.
Thanks
Peter
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman
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 befo
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 d
On Wed, Dec 15, 2010 at 3:26 PM, Robert Raszuk 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
>
>
On 16/12/2010 20:00, John Scudder wrote:
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 s
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 m
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.
>
> P
Thu, Dec 16, 2010 at 05:02:43PM +, Nick Hilliard:
> But the alternative (screen scraping) is worse. Also it's got the advantage
> that my current monitoring systems support it, so monitoring my bgp sessions
> is just a matter of changing a few lines in my provisioning system, rather
> than w
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.
Yes, it's a ghastly protocol, and the bgp4mibv2 will cause all sorts of
horrible contortions. But the alternative (screen scraping) is worse. Also it's
got the advantage that my current monitoring systems support it, so monitoring
my bgp sessions is just a matter of changing a few lines in my pr
Nick,
Addressing one specific point:
On Wed, Dec 15, 2010 at 11:16:06PM +, Nick Hilliard wrote:
> 2. I would much prefer to see support for bgp4mibv2 on regular routers,
> rather than a completely new tool (although I do acknowledge the
> necessity of being able to peek into ribs, and that
12 matches
Mail list logo
