Nick,
Those who do not automate may not even look at the syslog at all. I those
cases as Jared said adding it to sh bgp neig may help with the risk of
having the screen scraping parsers broken.
As to what's the point of this discussion ... is to not change format of
NOTFICATION as per 4271 yet d
Neil J. McRae wrote:
> I just wish I thought we had the luxury of lazy operations like this!
to clarify my previous email, it's a matter of simple economics:
automation needs scale to work properly, and in particular, bgp session
management automation only makes sense for a relatively small number
I'd argue that, even when someone has no interest to use the Shutdown
Communications sent by others, they can benefit and save time by using the
feature to inform their customers or peers of shutdown reasons. Sending and
receiving are two separate considerations.
Kind regards,
Job
> On 19 Nov
Neil J. McRae wrote:
> I just wish I thought we had the luxury of lazy operations like this!
there are more places in heaven and earth, Neil, including many places
where automation makes no sense and many other places where unstructured
text would be a useful tool in the operator's box. Just beca
I just wish I thought we had the luxury of lazy operations like this!
Neil
> On 19 Nov 2016, at 19:41, Job Snijders wrote:
>
>> On Sat, Nov 19, 2016 at 05:23:15PM +, Neil J. McRae wrote:
>> It's a wonderfully useless solution when it could be a wonderfully
>> useful solution - it's just mo
On Sat, Nov 19, 2016 at 05:23:15PM +, Neil J. McRae wrote:
> It's a wonderfully useless solution when it could be a wonderfully
> useful solution - it's just more operational noise that we already
> have and we will start filtering like everything else.
What's really useless is hyperbole arg
It's a wonderfully useless solution when it could be a wonderfully useful
solution - it's just more operational noise that we already have and we will
start filtering like everything else.
Neil.
> On 19 Nov 2016, at 16:58, Marco Marzetti wrote:
>
> Robert,
>
> This is a wonderful easy to
Robert,
This is a wonderful easy to use solution to send informational
messages to your neighbor for a very specific case (sesssion shutdown)
It is so easy that i wonder why we're discussing for so lo long.
Changing operational patterns or having well-formatted messages is out
of the scope and do
On Sat, Nov 19, 2016 at 05:07:50PM +0100, Robert Raszuk wrote:
> If you think this is too much then let's support new message type (for
> example Advisory) which will be able to be sent ahead of planned admin
> shutdown with all details necessary and be done.
"Shutdown" and "advisory"-style messag
If you think this is too much then let's support new message type (for
example Advisory) which will be able to be sent ahead of planned admin
shutdown with all details necessary and be done.
Regards,
R.
On Sat, Nov 19, 2016 at 4:56 PM, Jeffrey Haas wrote:
>
> On Nov 19, 2016, at 10:48 AM, Rober
> On Nov 19, 2016, at 10:48 AM, Robert Raszuk wrote:
>
> > What would the distinction between admin shutdown (clear) vs. info-read the
> > friendly message be?
>
> Ordering ...
>
> You define a subcode or even new code as NOTIFICATION INFO and that is by
> the spec NOT to trigger the TCP
> What would the distinction between admin shutdown (clear) vs. info-read
the friendly message be?
Ordering ...
You define a subcode or even new code as NOTIFICATION INFO and that is by
the spec NOT to trigger the TCP reset .. before you get subsequent error
code and subcode (when applicable).
> On Nov 19, 2016, at 10:16 AM, Robert Raszuk wrote:
>
> Jeff,
>
> > Part of the motivation I had for suggesting the use of an existing sub-code
> > is we have *not* changed the semantics in a machine-readable format.
> > It's still "administrative shutdown". Today, you'd have zero extra
>
Jeff,
> Part of the motivation I had for suggesting the use of an existing
sub-code
> is we have *not* changed the semantics in a machine-readable format.
> It's still "administrative shutdown". Today, you'd have zero extra
information
> what it's about.
My interpretation of 4271 does not prohi
> On Nov 19, 2016, at 10:10 AM, Robert Raszuk wrote:
>
>
> Leave alone that this all makes sense to be sent well before the planned
> admin shutdown so the other side is first aware of it and can manually or
> automatically take users off that peering.
>
> But looks like we are light years
Leave alone that this all makes sense to be sent well before the planned
admin shutdown so the other side is first aware of it and can manually or
automatically take users off that peering.
But looks like we are light years away from such basic thing here
On Sat, Nov 19, 2016 at 3:59 PM, Nei
> On Nov 19, 2016, at 9:59 AM, Neil J. McRae wrote:
>
> We shouldn't be encouraging folks to build networks that for routine events
> we then require more manual intervention when it's unwarranted.
>
> Why does it need to be free format?
Part of the motivation I had for suggesting the use of
We shouldn't be encouraging folks to build networks that for routine events we
then require more manual intervention when it's unwarranted.
Why does it need to be free format?
How many reasons or signals does one need to send in a message like this? Just
thinking whilst I wait for the till to
Nick,
I am not going to argue with few of you here who want free form text
and do not accept any suggestions.
But if you can not parse few defined keywords in any free form text to
enable better
automated interpretation of the message I think there is more problems
here. TLV within current NOTIFI
Robert Raszuk wrote:
> Just to be clear: I am also OK with free form text with the few well
> known and easy to machine parse keywords (in it).
the field should either be fully structured or free-form, and the
explicit intent of this draft is free form, utf8. Having a half-way
house is in nobody'
Marco,
Just to be clear: I am also OK with free form text with the few well known
and easy to machine parse keywords (in it). Of course provided that we
either forget about new length field in subcode 2 which would update 4271
or we do it in new subcode all together.
Thx,
R.
On Sat, Nov 19, 2016
Robert,
Just to be clear: i am supporting free text as i don't think that we
should enforce any kind of formatting for any reason.
Regards
On Sat, Nov 19, 2016 at 3:07 PM, Robert Raszuk wrote:
> Marco,
>
> Yes indeed. As said it would be completely optional.
>
> Job,
>
> Free form is so old fas
Whow ... extremely well said !
The idea for phone number beats me ... who uses voice phones these days ???
Cheers,
R.
On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae wrote:
> I personally think this is a really bad idea but understand why some might
> want this - and we've had similar drafts
Marco,
Yes indeed. As said it would be completely optional.
Job,
Free form is so old fashioned that it really does not even sound
reasonable. Why do you want everything to be "figured out" outside of IDR ?
Why for everything we recently propose there must be 5 documents to read
all in different
Robert,
So you're suggesting to include recommendation for the formatting?
That could help (as long as it's not mandatory).
Regards
On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae wrote:
> I personally think this is a really bad idea but understand why some might
> want this - and we've had si
I personally think this is a really bad idea but understand why some might want
this - and we've had similar drafts in the past- in my view we shouldn't be
moving more towards more human related randomness in system level messages -
have a set of status numbers or something that can be predicta
Siriam,
I wasn't at the meeting, so pardon me if you've already discussed that there.
So you are suggesting that every customers can send packets that other
customer's IPs in the source field?
Is that correct?
Anyway:
Have you considered the additional burden on routers to handle that?
And what a
On Fri, Nov 18, 2016 at 08:01:30PM +, Jakob Heitz (jheitz) wrote:
> Not necessary. You can already send whatever you want. In iOS-XR, it just
> hexdumps it all. The only thing that will change is that it will print it in
> UTF8 as well. It will still hexdump. If you want no hexdump, then we n
28 matches
Mail list logo
