Hi Jim,I very much share your point of view. I think the current version of the draft may be a good starting point for the discussion as apparently there is operator's community requirement for improvement in the space of inter-NOC communication.
I think automation is great and if we can automate anything I am always in support. If this regardless of comments already made in the other thread is to happen in BGP so be it.
Would we have a way to keep this new communication channel to BGP related messages - perhaps no.
Example: If EBGP peers agree to run BFD would we use the same new BGP msg type channel to pass BFD related warnings too ?
But in spite of couple of people's immediate voting to accept it "as is" or "exactly as written" which interestingly enough Ron's email did not even contained in the question I would like to state that "as is" or "exactly as written" may be a bit too strong of requirement.
Besides which version of the draft are we talking of "as is" ? Those in version -00 or those on Nanog slides including "good ideas" from pages 11 & 12 ?
http://www.nanog.org/meetings/nanog46/presentations/Tuesday/Scholl_bgp_adv_light_N46.pdf Example: Concept of sticky messages•An idea where you can transmit an advisory message to “stick” in the BGP neighbor state. This way, upon viewing “show bgp nei x.x.x.x”, you can see the latest sticky message transmitted by the peer.
•Would not be sent to the log.Question: How can something with random length (without max limit) be part of cli show command and yet still make this show command nicely readable and parsable by scripts ?
So I would suggest both for sticky msg and syslog msg to have max length defined.
Also I think we should enforce the free form language to be ASCII English only.
/* And yes I can already see a request coming for a spell checker to be added to router's OS ... After all it is in the cell phone why not in the router :-) */
Cheers, R.
Hello folks,
I support adopting this as a WG item.
However, and I'm sure we will get into this as the WG proceeds, I think
there are fundamental elements of this which are bad. Notably, I don't
think that bloating BGP with operator-to-operator messages is a good
move to maintain a stable, secure (fwiw) protocol.
I agree that the problem of op-2-op communication needs more attention,
and I hope with this starting point the WG can forge a reasonable
solution that doesn't increase the fragility and risk of operating an
Internetwork.
--gill
-----Original Message-----
From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
Ron Bonica
Sent: Tuesday, June 30, 2009 1:58 PM
To: idr at ietf.org
Subject: [Idr] draft-scholl-idr-advisory
Folks,
Last month, Tom Scholl presented draft-scholl-idr-advisory to NANOG's
general meeting in Philadelphia. The operator community demonstrated
strong support for the draft.
In light of strong operator support, I would like to encourage the WG to
consider adopting this draft as a WG item.
Ron Bonica
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr