Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[joel jaeggli]

On 11/29/16 11:31 AM, Randy Bush wrote:
> why do folk block syslog/514?
because spoofing syslog entries is a thing. in general I don't let
member of the general public emit junk into my logs except of course
spammers who are quite well represented albeit indirectly, as is the
case here.
> who can come up with the first exploit based on a tricky entry?
it's a fairly narrow surface area on the syslog reciver given the
emitter is the routers syslogd so for example something like

http://www.rsyslog.com/remote-syslog-pri-vulnerability/

is under the control of the syslogd not the sender.

128 characters is of somewhat limited value in syslog spoofing as you
have to flap you bgp session in order to emit a new line.

do you think reciver operation should be more tightly specified in some way?

thanks
joel
> randy
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>




signature.asc
Description: OpenPGP digital signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Randy Bush]

why do folk block syslog/514?
who can come up with the first exploit based on a tricky entry?

randy

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[John G. Scudder]

On Nov 20, 2016, at 5:09 AM, Job Snijders  wrote:
> I'd like to ask the chairs to move 'draft-ietf-idr-operational-message-00' to 
> 'Dead' status.

Your request is acknowledged, but IMO beyond the scope of this discussion. 

Look for a discussion of zombified drafts and what to do about them at our next 
meeting (or maybe on-list before). 

--John
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[joel jaeggli]

On 11/20/16 3:21 PM, Robert Raszuk wrote:
>
>
> > I'd like to ask the chairs to move
> 'draft-ietf-idr-operational-message-00' to 'Dead' status.
>
> It bothers you so much that it is a WG doc ?
>
> Or is the issue that it does not define fixed field for plain
> telephone number to dial ?
>
Not revved since 2012 seems like a problem.

To me the sticking point with expressing more complex information as
with proposed dump state and control tlvs involves the opportunity to
hose up signaling in new interesting ways.

Whether I think they should be more expressive or not; job's proposal
has the inherent safety of arriving on a cease which I'm pretty sure
doesn't leave much to the imagination.

> R.
>
>
>
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr





signature.asc
Description: OpenPGP digital signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Sam Silvester]

On Mon, Nov 21, 2016 at 5:04 AM, Gaurab Raj Upadhaya 
wrote:

> On 11/19/16 9:58 PM, Nick Hilliard wrote:
> > Regarding the I-D, there are ~55000 asns visible in the dfz, of
> > which ~6000-7000 are non-leaf, and probably less than a thousand
> > where bgp session automation makes financial sense.  No doubt,
> > as5400/2856 would be in the top bracket of these and it would make
> > sense for your tooling teams to automate the hell out of nearly
> > everything, which would militate against accepting free-form advisory
> > shutdown notices like this - but then again, BT is atypical in the
> > general scheme of things. Whether you like it or not, the long tail
> > of ASNs would benefit from a simple mechanism of this form.
>

I completely agree with this also. It's a no-brainer to me, I would love
this functionality and I can think of plenty of times on both a sending and
receiving end that this would have been a nice to have thing.


> that sums it up neatly for me. I also think that adding complexity in
> the free form at this stage may limit implementation and the numerous
> ways in which it can be used for automation.
>

I would also recommend no explicit or suggested terms are added in the ID.
Leave it open ended and see how it goes. At the end of the day, it
shouldn't matter to those implementing BGP speaker software, so why mention
it at all in the ID?

I support this proposal, would love to see it make it out the door in terms
of shipping code.

Regards,

Sam
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Robert Raszuk]

> I'd like to ask the chairs to move
'draft-ietf-idr-operational-message-00' to 'Dead' status.

It bothers you so much that it is a WG doc ?

Or is the issue that it does not define fixed field for plain telephone
number to dial ?

R.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Nick Hilliard]

Neil J. McRae wrote:
> I would be deploying automation to take care of network
> problems/issues/whatever whether I worked at BT or I was the admin of
> a network with four and a half nodes.

For sure.  e.g. we've automated the hell out of INEX (which has more
than 4.5 nodes btw).  The point is that most ASNs are a good deal
smaller than this, and less amenable to automation than IXPs.  There's
simply no point in writing automation software to handle one or two
routers with 5 or fewer ebgp sessions between them, which describes the
overwhelming majority of ASNs in the world.

> We have the world and his wife automating and innovating on top of
> -our- internet platform and we are still encouraging behaviours like
> it was 1992 (I'd say like mission control in the 60s but I think they
> had more automation back then!)

Rather than castigating people for their shortsightedness, did you take
the time to ask e.g. Job why a large carrier like NTT might want this
feature?  Their network is likely to be highly automated.

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Neil J. McRae]

I would be deploying automation to take care of network 
problems/issues/whatever whether I worked at BT or I was the admin of a network 
with four and a half nodes.

We have the world and his wife automating and innovating on top of -our- 
internet platform and we are still encouraging behaviours like it was 1992 (I'd 
say like mission control in the 60s but I think they had more automation back 
then!) 

oh well if we just want to be the dumb pipe providers! 

> On 20 Nov 2016, at 18:34, Gaurab Raj Upadhaya  wrote:
> 
>> On 11/19/16 9:58 PM, Nick Hilliard wrote:
>> Regarding the I-D, there are ~55000 asns visible in the dfz, of
>> which ~6000-7000 are non-leaf, and probably less than a thousand
>> where bgp session automation makes financial sense.  No doubt,
>> as5400/2856 would be in the top bracket of these and it would make
>> sense for your tooling teams to automate the hell out of nearly
>> everything, which would militate against accepting free-form advisory
>> shutdown notices like this - but then again, BT is atypical in the
>> general scheme of things. Whether you like it or not, the long tail
>> of ASNs would benefit from a simple mechanism of this form.
> 
> that sums it up neatly for me. I also think that adding complexity in
> the free form at this stage may limit implementation and the numerous
> ways in which it can be used for automation.
> 
> I see these quite similar to TXT records in DNS. and so, I do think that
> at some point after this has been implemented, we'll need to document
> widely adopted structures in a BCP.
> 
> -gaurab
> 
> 
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Gaurab Raj Upadhaya]

On 11/19/16 9:58 PM, Nick Hilliard wrote:
> Regarding the I-D, there are ~55000 asns visible in the dfz, of
> which ~6000-7000 are non-leaf, and probably less than a thousand
> where bgp session automation makes financial sense.  No doubt,
> as5400/2856 would be in the top bracket of these and it would make
> sense for your tooling teams to automate the hell out of nearly
> everything, which would militate against accepting free-form advisory
> shutdown notices like this - but then again, BT is atypical in the
> general scheme of things. Whether you like it or not, the long tail
> of ASNs would benefit from a simple mechanism of this form.

that sums it up neatly for me. I also think that adding complexity in
the free form at this stage may limit implementation and the numerous
ways in which it can be used for automation.

I see these quite similar to TXT records in DNS. and so, I do think that
at some point after this has been implemented, we'll need to document
widely adopted structures in a BCP.

-gaurab





signature.asc
Description: OpenPGP digital signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Robert Raszuk]

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 define someting even if not structured to be
machine readable.

Thx
R.

On Nov 20, 2016 6:58 AM, "Nick Hilliard"  wrote:

> 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 of
> networks worldwide because the cost*risk to return ratio is wrong in
> most cases.  This is particularly the case because of poor availability
> of good tooling.
>
> Regarding the I-D, there are ~55000 asns visible in the dfz, of which
> ~6000-7000 are non-leaf, and probably less than a thousand where bgp
> session automation makes financial sense.  No doubt, as5400/2856 would
> be in the top bracket of these and it would make sense for your tooling
> teams to automate the hell out of nearly everything, which would
> militate against accepting free-form advisory shutdown notices like this
> - but then again, BT is atypical in the general scheme of things.
> Whether you like it or not, the long tail of ASNs would benefit from a
> simple mechanism of this form.
>
> Nick
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Nick Hilliard]

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 of
networks worldwide because the cost*risk to return ratio is wrong in
most cases.  This is particularly the case because of poor availability
of good tooling.

Regarding the I-D, there are ~55000 asns visible in the dfz, of which
~6000-7000 are non-leaf, and probably less than a thousand where bgp
session automation makes financial sense.  No doubt, as5400/2856 would
be in the top bracket of these and it would make sense for your tooling
teams to automate the hell out of nearly everything, which would
militate against accepting free-form advisory shutdown notices like this
- but then again, BT is atypical in the general scheme of things.
Whether you like it or not, the long tail of ASNs would benefit from a
simple mechanism of this form.

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders]

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 2016, at 22:16, Nick Hilliard  wrote:
> 
> 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 because BT
> wouldn't use this, that doesn't invalidate its utility.
> 
> Nick
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Nick Hilliard]

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 because BT
wouldn't use this, that doesn't invalidate its utility.

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders]

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 argumentation. :-) Don't forget to
recognise that your network operations might differ from how other
people operate their network.

A common pattern:

supplier: "2 weeks from now at 18:00 UTC we will do maintenance XYZ on 
router ABC, this work is tracked in V-NOC-24789244"
*two weeks pass*
*supplier starts the work*
*customer sees BGP session with router ABC go down*
customer calls supplier's NOC: "hey my session is down, whats up!?"

If in the above scenario the customer had seen "V-NOC-24789244 maintenace 
started" in their syslog (where they started their
investigation), the customer would search for the V-NOC-24789244 string
in their mailbox and all details would become clear. I think this is
useful and a good starting point.

I suspect that where Neil is coming from, the customer would have
already parsed the maintenance notification 2 weeks before the
maintenance work, and added that to their organisational-wide calendar,
pre-silenced alerts, drained the traffic away, etc.

The "shutdown" draft is not a replacement for efforts such as
https://www.maintenancemanager.org/ - but maybe, when "shutdown" is more
ubiquitously available, it could be a component in such maintenance
manager toolchains.

Maybe in 2 or 3 years time we'll revisit the topic and based on that
operational experience define a taxonomy and create a structured
approach. Maybe the structured approach will be entirely out-of-band
(companies posting yang to each others' maintenance API endpoints?).  I
think the free form approach is an excellent starting point to see (and
immediately benefit) how a tool like this is used in the wild.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Neil J. McRae]

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 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 don't relate to the draft.
> What i mean is you can't say the proposal is not good just because
> stupid people do stupid things in other circumstances (like sending
> maintenance alerts)
> 
> Regards
> 
> 
>> On Sat, Nov 19, 2016 at 4:10 PM, 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 away from such basic thing here 
>> 
>>> On Sat, Nov 19, 2016 at 3:59 PM, 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?
>>> 
>>> How many reasons or signals does one need to send in a message like this?
>>> Just thinking whilst I wait for the till to be rebooted in WHSmiths -  I can
>>> think of 3 different cease reasons (and 1 of them is a form of the other).
>>> De-peer; maintenance;  problem call/contact us - what else ? Enough to
>>> trigger info is in the existing config to trigger you to the right
>>> information on peeringdb or other local database.
>>> 
>>> Cheers,
>>> Neil
>>> 
>>> Sent from my iPhone
>>> 
 On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
 
 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's interest because the discussion will then rat-hole
 on defining a new ad-hoc quasi-language, and the draft - if it ever gets
 turned into running code - will end up being a protocol soup which
 no-one will find satisying.
 
 If you feel it should be fully structured, then please feel free to
 submit an alternative draft to that effect.
 
 Nick
>> 
>> 
> 
> 
> 
> -- 
> Marco

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Marco Marzetti]

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 don't relate to the draft.
What i mean is you can't say the proposal is not good just because
stupid people do stupid things in other circumstances (like sending
maintenance alerts)

Regards


On Sat, Nov 19, 2016 at 4:10 PM, 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 away from such basic thing here 
>
> On Sat, Nov 19, 2016 at 3:59 PM, 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?
>>
>> How many reasons or signals does one need to send in a message like this?
>> Just thinking whilst I wait for the till to be rebooted in WHSmiths -  I can
>> think of 3 different cease reasons (and 1 of them is a form of the other).
>> De-peer; maintenance;  problem call/contact us - what else ? Enough to
>> trigger info is in the existing config to trigger you to the right
>> information on peeringdb or other local database.
>>
>> Cheers,
>> Neil
>>
>> Sent from my iPhone
>>
>> > On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
>> >
>> > 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's interest because the discussion will then rat-hole
>> > on defining a new ad-hoc quasi-language, and the draft - if it ever gets
>> > turned into running code - will end up being a protocol soup which
>> > no-one will find satisying.
>> >
>> > If you feel it should be fully structured, then please feel free to
>> > submit an alternative draft to that effect.
>> >
>> > Nick
>
>



-- 
Marco

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders]

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 messaging are not mutually exclusive.
They do not overlap in terms of technology and usage. Shutdown is useful
for when the session goes down, 'advisory' can be useful when the
session is still up.

An advantage of the 'shutdown' message is that there is an absolute
correlation between the message contained in the Shutdown Communication
and the (in cisco-speak) "ROUTING-BGP-5-ADJCHANGE" event itself.

"Shutdown" fits neatly into the existing BGP framework and has a low
barrier to entry for implementors.

Regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jeffrey Haas]

> 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 away from such basic thing here  

That was part of my motivation about asking about the already-adopted Advisory 
draft still being relevant.  

The shutdown draft requires no changes for any useful backward compatibility.  
But in order to signal such other information, the routers in question would 
need to support Advisory.

Although, personally, I'd rather just get an email to my noc@ address than have 
to scrape my syslog that maintenance is about to occur unexpectedly.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Robert Raszuk]

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, 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?
>
> How many reasons or signals does one need to send in a message like this?
> Just thinking whilst I wait for the till to be rebooted in WHSmiths -  I
> can think of 3 different cease reasons (and 1 of them is a form of the
> other). De-peer; maintenance;  problem call/contact us - what else ? Enough
> to trigger info is in the existing config to trigger you to the right
> information on peeringdb or other local database.
>
> Cheers,
> Neil
>
> Sent from my iPhone
>
> > On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
> >
> > 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's interest because the discussion will then rat-hole
> > on defining a new ad-hoc quasi-language, and the draft - if it ever gets
> > turned into running code - will end up being a protocol soup which
> > no-one will find satisying.
> >
> > If you feel it should be fully structured, then please feel free to
> > submit an alternative draft to that effect.
> >
> > Nick
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jeffrey Haas]

> 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 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.

The problem with attempting to move to the next set of levels of machine 
parseability is enumerating the full set of reasons that you would do such a 
shutdown.  

IMO, we're better off leaving this as freeform text.  I'd also encourage the 
regional operators to think about what they'd like to *see* in such fields.  
Just because the protocol doesn't mandate fields doesn't mean you couldn't 
provide guidance as to what goes in there.  

Jared's case is what I find to be the normal one:
- NOC contact#
- NOC ticket#
- Short reason why the session is down. (E.g. "you didn't pay your bill!")

Again, the key is that the machine readable - and BGP standards backward 
compatible bit - hasn't changed.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Neil J. McRae]

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 be rebooted in WHSmiths -  I can think 
of 3 different cease reasons (and 1 of them is a form of the other). De-peer; 
maintenance;  problem call/contact us - what else ? Enough to trigger info is 
in the existing config to trigger you to the right information on peeringdb or 
other local database.

Cheers,
Neil 

Sent from my iPhone

> On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
> 
> 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's interest because the discussion will then rat-hole
> on defining a new ad-hoc quasi-language, and the draft - if it ever gets
> turned into running code - will end up being a protocol soup which
> no-one will find satisying.
> 
> If you feel it should be fully structured, then please feel free to
> submit an alternative draft to that effect.
> 
> Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Nick Hilliard]

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's interest because the discussion will then rat-hole
on defining a new ad-hoc quasi-language, and the draft - if it ever gets
turned into running code - will end up being a protocol soup which
no-one will find satisying.

If you feel it should be fully structured, then please feel free to
submit an alternative draft to that effect.

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Robert Raszuk]

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 at 3:27 PM, Marco Marzetti  wrote:

> 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 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 forums/groups to use it ? Do you prefer to hard encode TLVs to
> > make the proposal parsable ?
> >
> > Please remember you are extending BGP as the protocol used by many who do
> > not even know what IDR or GROW is. Not everyone who uses BGP has time for
> > IETF or NANOG or RIPE.
> >
> > Cheers,
> > R.
> >
> >
> >
> > On Sat, Nov 19, 2016 at 2:56 PM, Marco Marzetti 
> wrote:
> >>
> >> 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 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
> >> > predictable but randomly "we took the peer down whilst we went to
> >> > McDonald's" as opposed to CEASE reason 666 - we depeered or reason
> 999 we
> >> > have a problem call us would be a much better approach. We can't keep
> >> > running networks like we did 20 years ago!
> >> >
> >> > Thanks
> >> > Neil
> >> > Sent from my iPhone
> >> >
> >> >> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
> >> >>
> >> >> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
> >> >> :I hope to capture in the draft that an implementation can choose
> which
> >> >> :characters of the Shutdown Communication they represent in the
> syslog
> >> >> or
> >> >> :'show bgp neighbor xxx' output. For instance, I'd recommend to
> squash
> >> >> :all newline/newpage/newfeed/newparagraph style chars and make sure
> >> >> that
> >> >> :the Communication is represented on a single line. I don't have the
> >> >> :proper words for the draft to express that (yet).
> >> >>
> >> >> I've been thinking about wording for protecting the receiving system
> >> >> from possible bad input.  I'm not worried about (valid) UTF-8 display
> >> >> chars, nor about whitespace things.  I am worried about Little Bobby
> >> >> Tables, though.
> >> >>
> >> >> We also have to consider that this will be displayed possibly in a
> Unix
> >> >> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
> >> >> chars have different meanings there.
> >> >>
> >> >> I'm not quite happy with the wording, but I would like something
> along
> >> >> these lines added.  Possibly in the Security section, or at the end
> of
> >> >> Section #2.
> >> >>
> >> >> 
> >> >> Receiving systems SHOULD filter the message for the intended output
> >> >> environment and MAY change octets or sequences of octets for their
> >> >> local environment.
> >> >> As the message may be displayed on a command line, stored
> >> >> in a syslog server, in an SQL database, or even a Web Server
> different
> >> >> outputs MAY happen.
> >> >> Sending systems MUST NOT depend on changes to their
> >> >> sequences not happening.
> >> >> 
> >> >>
> >> >> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
> >> >> escapes, Javascript/HTML, etc)
> >> >>
> >> >>
> >> >> --
> >> >> Taxes, n.:
> >> >>Of life's two certainties, the only one for which you can get
> >> >>an extension.
> >> >>
> >> >> ___
> >> >> Idr mailing list
> >> >> i...@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/idr
> >> >
> >> > ___
> >> > GROW mailing list
> >> > GROW@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/grow
> >>
> >>
> >>
> >> --
> >> Marco
> >>
> >> ___
> >> GROW mailing list
> >> GROW@ietf.org
> >> https://www.ietf.org/mailman/listinfo/grow
> >
> >
>
>
>
> --
> Marco
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Marco Marzetti]

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 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 
> predictable but randomly "we took the peer down whilst we went to McDonald's" 
> as opposed to CEASE reason 666 - we depeered or reason 999 we have a problem 
> call us would be a much better approach. We can't keep running networks like 
> we did 20 years ago!
>
> Thanks
> Neil
> Sent from my iPhone
>
>> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
>>
>> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
>> :I hope to capture in the draft that an implementation can choose which
>> :characters of the Shutdown Communication they represent in the syslog or
>> :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
>> :all newline/newpage/newfeed/newparagraph style chars and make sure that
>> :the Communication is represented on a single line. I don't have the
>> :proper words for the draft to express that (yet).
>>
>> I've been thinking about wording for protecting the receiving system
>> from possible bad input.  I'm not worried about (valid) UTF-8 display
>> chars, nor about whitespace things.  I am worried about Little Bobby
>> Tables, though.
>>
>> We also have to consider that this will be displayed possibly in a Unix
>> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
>> chars have different meanings there.
>>
>> I'm not quite happy with the wording, but I would like something along
>> these lines added.  Possibly in the Security section, or at the end of
>> Section #2.
>>
>> 
>> Receiving systems SHOULD filter the message for the intended output
>> environment and MAY change octets or sequences of octets for their
>> local environment.
>> As the message may be displayed on a command line, stored
>> in a syslog server, in an SQL database, or even a Web Server different
>> outputs MAY happen.
>> Sending systems MUST NOT depend on changes to their
>> sequences not happening.
>> 
>>
>> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
>> escapes, Javascript/HTML, etc)
>>
>>
>> --
>> Taxes, n.:
>>Of life's two certainties, the only one for which you can get
>>an extension.
>>
>> ___
>> Idr mailing list
>> i...@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



-- 
Marco

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Neil J. McRae]

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 predictable but randomly 
"we took the peer down whilst we went to McDonald's" as opposed to CEASE reason 
666 - we depeered or reason 999 we have a problem call us would be a much 
better approach. We can't keep running networks like we did 20 years ago! 

Thanks
Neil 
Sent from my iPhone

> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
> 
> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
> :I hope to capture in the draft that an implementation can choose which
> :characters of the Shutdown Communication they represent in the syslog or
> :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> :all newline/newpage/newfeed/newparagraph style chars and make sure that
> :the Communication is represented on a single line. I don't have the
> :proper words for the draft to express that (yet).
> 
> I've been thinking about wording for protecting the receiving system
> from possible bad input.  I'm not worried about (valid) UTF-8 display
> chars, nor about whitespace things.  I am worried about Little Bobby
> Tables, though.
> 
> We also have to consider that this will be displayed possibly in a Unix
> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
> chars have different meanings there.
> 
> I'm not quite happy with the wording, but I would like something along
> these lines added.  Possibly in the Security section, or at the end of
> Section #2.
> 
> 
> Receiving systems SHOULD filter the message for the intended output
> environment and MAY change octets or sequences of octets for their   
> local environment.
> As the message may be displayed on a command line, stored
> in a syslog server, in an SQL database, or even a Web Server different
> outputs MAY happen.
> Sending systems MUST NOT depend on changes to their
> sequences not happening.
> 
> 
> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
> escapes, Javascript/HTML, etc) 
> 
> 
> -- 
> Taxes, n.:
>Of life's two certainties, the only one for which you can get
>an extension.
> 
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jared Mauch]

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 need a 
> new subcode.
> 

One other thing we will need from the vendors is
the information to be available in the show commands around the
BGP neighbor as well, eg:

Router#show bgp neighbor

BGP neighbor is fe80::1
 Remote AS 65000, local AS 65000, internal link

  Connections established 1; dropped 0
  Last reset 2d03h, due to BGP Notification sent: code/text here
  Time since last notification sent to neighbor: 2d03h
  Error Code: appropriate code goes here
  Notification data received (or sent):
UTF-8 string goes here






-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jakob Heitz (jheitz)]

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 need a new 
subcode.

Thanks,
Jakob.

On Nov 18, 2016, at 12:52 AM, 
"bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>" 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:

Thanks.
--Bruno

From: Job Snijders [mailto:j...@instituut.net]
Sent: Friday, November 18, 2016 9:46 AM
To: DECRAENE Bruno IMT/OLN
Cc: Jeffrey Haas; Job Snijders; grow@ietf.org<mailto:grow@ietf.org>; 
i...@ietf.org<mailto:i...@ietf.org>
Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the 
peer's syslog at shutdown

Hi Bruno,

John Scudder was kind enough to provide extensive argumentation offlist on why 
something along these lines should be done. We'll work on a proposal. The 
length indicator is a neat idea, thanks for sharing.

Job

On Fri, 18 Nov 2016 at 17:32, 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:


> From: Job Snijders [mailto:j...@instituut.net<mailto:j...@instituut.net>]  > 
> Sent: Friday, November 18, 2016 1:46 AM
>
 > On Thu, Nov 17, 2016 at 04:28:50PM +, 
 > bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:
 > > I support the draft.
 > > I also support Jeff's idea to re-use existing sub-code(s).
 >
 > Thanks for your support. Based on the feedback received so far the next
 > version of this draft will recycle Cease subcode 2.
 >
 > > 1 possible comment: the length of the "Shutdown Communication" field
 > > seems implied from the length of the data field, rather than being
 > > explicitly indicated.
 >
 > The text is explicit about the length:
 >
 > "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
 > length of 128 octets. "
 >
 > and further:
 >
 > "This document tries to minimize the effects of visual spoofing by
 > allowing UNICODE only where local script is expected and needed, and
 > by limiting the length of the Shutdown Communication."
 >
 > > If so, it seems that we are closing the possibility to advertise
 > > additional data/usage, in some future. What about adding a TLV format?
 >
 > I object to using a TLV. Don't forget this is already at a TLV level:
 > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
 > new Cease subcode can be requested from IANA.

What if someone needs to advertise additional info to an existing cease 
subcode? cf Jeff's email regarding the pain of changing subcodes.
So let's forget about the TLV. What about just adding the length of the string? 
This would still allow adding fields after the string, while having a 
negligible/null cost?

Kind regards,
-- Bruno

 > Kind regards,
 >
 > Job

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not 

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders]

Hi Bruno,

John Scudder was kind enough to provide extensive argumentation offlist on
why something along these lines should be done. We'll work on a proposal.
The length indicator is a neat idea, thanks for sharing.

Job

On Fri, 18 Nov 2016 at 17:32,  wrote:

>
>
> > From: Job Snijders [mailto:j...@instituut.net]  > Sent: Friday, November
> 18, 2016 1:46 AM
> >
>  > On Thu, Nov 17, 2016 at 04:28:50PM +, bruno.decra...@orange.com
> wrote:
>  > > I support the draft.
>  > > I also support Jeff's idea to re-use existing sub-code(s).
>  >
>  > Thanks for your support. Based on the feedback received so far the next
>  > version of this draft will recycle Cease subcode 2.
>  >
>  > > 1 possible comment: the length of the "Shutdown Communication" field
>  > > seems implied from the length of the data field, rather than being
>  > > explicitly indicated.
>  >
>  > The text is explicit about the length:
>  >
>  > "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
>  > length of 128 octets. "
>  >
>  > and further:
>  >
>  > "This document tries to minimize the effects of visual spoofing by
>  > allowing UNICODE only where local script is expected and needed, and
>  > by limiting the length of the Shutdown Communication."
>  >
>  > > If so, it seems that we are closing the possibility to advertise
>  > > additional data/usage, in some future. What about adding a TLV format?
>  >
>  > I object to using a TLV. Don't forget this is already at a TLV level:
>  > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
>  > new Cease subcode can be requested from IANA.
>
> What if someone needs to advertise additional info to an existing cease
> subcode? cf Jeff's email regarding the pain of changing subcodes.
> So let's forget about the TLV. What about just adding the length of the
> string? This would still allow adding fields after the string, while having
> a negligible/null cost?
>
> Kind regards,
> -- Bruno
>
>  > Kind regards,
>  >
>  > Job
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders]

On Thu, Nov 17, 2016 at 04:28:50PM +, bruno.decra...@orange.com wrote:
> I support the draft.
> I also support Jeff's idea to re-use existing sub-code(s).

Thanks for your support. Based on the feedback received so far the next
version of this draft will recycle Cease subcode 2.

> 1 possible comment: the length of the "Shutdown Communication" field
> seems implied from the length of the data field, rather than being
> explicitly indicated. 

The text is explicit about the length:

"followed by a freeform UTF-8 encoded string with a REQUIRED maximum
length of 128 octets. "

and further:

"This document tries to minimize the effects of visual spoofing by
allowing UNICODE only where local script is expected and needed, and
by limiting the length of the Shutdown Communication."

> If so, it seems that we are closing the possibility to advertise
> additional data/usage, in some future. What about adding a TLV format?

I object to using a TLV. Don't forget this is already at a TLV level:
Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
new Cease subcode can be requested from IANA.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[bruno.decraene]

I support the draft.
I also support Jeff's idea to re-use existing sub-code(s).

1 possible comment: the length of the "Shutdown Communication" field seems 
implied from the length of the data field, rather than being explicitly 
indicated. If so, it seems that we are closing the possibility to advertise 
additional data/usage, in some future. What about adding a TLV format?

Thanks,
--Bruno


> From: Jeffrey Haas  Sent: Thursday, November 17, 2016 2:37 AM
 > To: Job Snijders
 > Cc: i...@ietf.org; grow@ietf.org
 > Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the 
 > peer's syslog
 > at shutdown
 > 
 > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
 > > Some might wonder, why "Cease"?
 > >
 > > The beauty of using a new Cease subcode, is that the NOTIFICATION
 > > message type already allows extra data to be attached, so for most
 > > implementations it will be very simple to bolt what is specified in
 > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
 > > cases we are looking at just a handful of lines.
 > 
 > As I commented elsewhere, changing subcodes ends up being painful from a
 > conformance standpoint.  I would honestly not recommend a new subcode.
 > 
 > BGP implementations usually deal with the notification data section that may
 > not have information in a format they recognize by simply ignoring or making
 > the contents available in something like hexadecimal prints.
 > 
 > What I would suggest is simply take the RFC 4486 subcodes that don't already
 > return additional information (e.g. max prefix) and simply add this shutdown
 > reason as the data.  From the list of code points, here's the ones I would
 > suggest updating:
 > 
 > : 2Administrative Shutdown
 > : 3Peer De-configured
 > : 6Other Configuration Change
 > 
 > Ones that possibly shouldn't be changed:
 > 
 > 
 > : 1Maximum Number of Prefixes Reached
 > 
 > This one is fully specified.
 > 
 > : 4Administrative Reset
 > 
 > I'm not sure returning something here makes sense.  This seems to be more
 > the "clear bgp neighbor" case.  Unless you think adding information about
 > why the user did the clear makes sense.
 > 
 > : 5Connection Rejected
 > 
 > Here's where things get a little odd.  You should get one of the other
 > subcodes on clear.  If you're preventing it from coming back up, this code
 > may be returned.  This means that even if you're storing the last received
 > string, it might be overwritten by this.
 > 
 > : 7Connection Collision Resolution
 > : 8Out of Resources
 > 
 > I suspect these shouldn't return anything.
 > 
 > > Previous attempts such as draft-ietf-idr-advisory-00 and
 > > draft-ietf-idr-operational-message-00 failed to deliver for various
 > > reasons (feature creep comes to mind), therefore we are trying to do
 > > this as simple as possible.
 > 
 > IMO, they more likely failed as low priority features that couldn't get past
 > product managers.
 > 
 > If, especially the existing code points are re-used and don't alter existing
 > implementation conformance, I suspect this draft would be closer to a
 > trivial modification that has a better chance of getting shipped quickly.
 > 
 > I also have to ask about:
 > 
 > :As of today these vendors have produced an implementation of the
 > :Shutdown Communication:
 > :
 > :o  ExaBGP
 > 
 > And exactly which code point did you squat on to do the prototype? ;-)
 > 
 > (I'm not exactly concerned about this since it's local in impact but you'd
 > think after the discussions this week...)
 > 
 > -- Jeff
 > 
 > ___
 > Idr mailing list
 > i...@ietf.org
 > https://www.ietf.org/mailman/listinfo/idr

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jakob Heitz (jheitz)]

I'm happy to keep the current subcode.

In today's IOS-XR implementation, we simply hexdump and trailing
octets after the subcode in "show bgp neighbor".
The new code could be to additionally print it in UTF8, after
validating it (no terminal escape sequences or other rubbish)
and truncating it at 128 octets. And syslog it if a valid string exists.

Thanks,
Jakob.


> -Original Message-
> From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Wednesday, November 16, 2016 5:47 PM
> To: Job Snijders <j...@ntt.net>
> Cc: i...@ietf.org; grow@ietf.org
> Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the 
> peer's syslog at shutdown
> 
> On Thu, Nov 17, 2016 at 10:42:15AM +0900, Job Snijders wrote:
> > On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> > > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > > > Some might wonder, why "Cease"?
> > > >
> > > > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > > > message type already allows extra data to be attached, so for most
> > > > implementations it will be very simple to bolt what is specified in
> > > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > > > cases we are looking at just a handful of lines.
> > >
> > > As I commented elsewhere, changing subcodes ends up being painful from a
> > > conformance standpoint.  I would honestly not recommend a new subcode.
> >
> > I don't follow, it seems you recommend to not change the behaviour of an
> > existing subcode (conformance), but you also recommend against getting a
> > new subcode?  Can you clarify?
> 
> No new subcodes.
> Add the text to the NOTIFICATION Data section of existing subcodes, when it
> makes sense and that Data section isn't otherwise specified.
> 
> -- Jeff
> 
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jeffrey Haas]

> On Nov 17, 2016, at 12:27 PM, Robert Raszuk  wrote:
> 
> Hi Job,
> 
> If safe extending subcode 2 would be fine, but even if router does not crash 
> or choke are we sure that all NMS reporting tools will also take the new msg 
> size just fine ?
> 
> 
It's clearly worth checking a few more implementations, but:
- The notification PDU makes allowances for optional data.
- If you get unexpected optional data, what are you going to do?  Send a 
notification? :-)
- If you crash, you have a much greater problem.


> If so or if we don't care I would say go for it. But if we are changing the 
> encoding now perhaps it would be better to issue 4486bis instead ...
> 
> 
Making this work a -bis is one way to proceed if the discussed behavior makes 
sense.  That said, it's perfectly fine to update a single sub-type in a 
standalone document that updates 4486.


-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Robert Raszuk]

Hi Job,

If safe extending subcode 2 would be fine, but even if router does not
crash or choke are we sure that all NMS reporting tools will also take the
new msg size just fine ?

If so or if we don't care I would say go for it. But if we are changing the
encoding now perhaps it would be better to issue 4486bis instead ...

Thx
R.

On Nov 17, 2016 12:06 PM, "Job Snijders"  wrote:

> On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > > Some might wonder, why "Cease"?
> > >
> > > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > > message type already allows extra data to be attached, so for most
> > > implementations it will be very simple to bolt what is specified in
> > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > > cases we are looking at just a handful of lines.
> >
> > As I commented elsewhere, changing subcodes ends up being painful from
> > a conformance standpoint.  I would honestly not recommend a new
> > subcode.
> >
> > BGP implementations usually deal with the notification data section
> > that may not have information in a format they recognize by simply
> > ignoring or making the contents available in something like
> > hexadecimal prints.
> >
> > What I would suggest is simply take the RFC 4486 subcodes that don't
> > already return additional information (e.g. max prefix) and simply add
> > this shutdown reason as the data.  From the list of code points,
> > here's the ones I would suggest updating:
> >
> > : 2Administrative Shutdown
> > : 3Peer De-configured
> > : 6Other Configuration Change
>
> > 
>
> I checked with Jakob, according to him IOS XR won't choke on a cease
> subcode 2 if there is trailing data.
>
> The UI or configuration concept of some operating systems might have
> trouble properly sending a 'cease "Peer De-configured"' with trailing
> data, so I'd skip that one for now. Same applies for 'other
> configuration change'.
>
> >From the looks of it, we can retrofit 'shutdown' under subcode 2 and
> forgo requesting a new cease subcode. I think I'd leave 3 and 6 as they
> are.
>
> Does anyone object to using subcode 2 for draft-snijders-idr-shutdown-01?
>
> The length of the NOTIFICATION will signal whether there is a shutdown
> communication or not.
>
> Kind regards,
>
> Job
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jeffrey Haas]

On Thu, Nov 17, 2016 at 10:24:28AM +0900, Job Snijders wrote:
> On Wed, Nov 16, 2016 at 08:19:45PM -0500, Jeffrey Haas wrote:
> > I think your doc is the first one that I've seen bothering to cite the
> > unicode considerations documents.  Ideally that'd be a pointer to somewhere
> > else in a single ref, but I don't think I've seen such an IETF document.
> 
> I took inspiration from syslog's security considerations 
> https://tools.ietf.org/html/rfc5424

IMO, just refer to that and delete a bunch of text from yours. :-)

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders]

On Wed, Nov 16, 2016 at 08:19:45PM -0500, Jeffrey Haas wrote:
> On Wed, Nov 16, 2016 at 10:01:10PM +0900, Job Snijders wrote:
> > Unless some implementors make significant arguments along the lines of
> > "we CANNOT implement this Shutdown Communication functionality, SOLELY
> > because of utf8 and lack of representation filtering capabilities", i'd
> > water down the utf8 requirement to 7bit ascii (because in the end its
> > better to have 'something' than nothing). Another line of argumentation
> > against utf8 would be if major security concerns are articulated.
> 
> In general, IESG comments will push any user-displayable string to UTF-8
> anyway, so I wouldn't stress over this being the requirement.  It's pretty
> much an IETF-wide expectation these days.
> 
> I think your doc is the first one that I've seen bothering to cite the
> unicode considerations documents.  Ideally that'd be a pointer to somewhere
> else in a single ref, but I don't think I've seen such an IETF document.

I took inspiration from syslog's security considerations 
https://tools.ietf.org/html/rfc5424

> > I hope to capture in the draft that an implementation can choose which
> > characters of the Shutdown Communication they represent in the syslog or
> > 'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> > all newline/newpage/newfeed/newparagraph style chars and make sure that
> > the Communication is represented on a single line. I don't have the
> > proper words for the draft to express that (yet).
> 
> Again, perhaps too much to tackle in this document.
> 
> A portion of what you're interested in is covered under the control
> characters section:
> 
> https://en.wikipedia.org/wiki/Unicode_control_characters
> 
> If you try to get too normative you're going to spend a huge amount of text
> trying to close all of the holes.

Yes, and UNICODE is somewhat of a moving target, a wall of text won't be
effective.

> > Also I don't mind if an implementation consciously chooses to only
> > represent 7bit ASCII. That should be an implementor decision. They can
> > upgrade later. In theory the protocol spec shouldn't be delayed or
> > obstructed due to an implementor's current internationalisation
> > capabilities (which can change over time).
> 
> ASCII is conformant UTF-8, which is one of the nice properties about that
> encoding.  What tends to be problematic in many people's implementations is
> emitting Latin-1 or similar encodings that are 8-bit as if they're valid
> UTF-8, which they're not.
> 
> The better question is what the general expected behavior is when things
> cannot be displayed.  Some of that will depend on the i18n capabilities of
> someone's implementation.

I'd just skip over them.

grã©gory -> grgory

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jeffrey Haas]

On Wed, Nov 16, 2016 at 10:01:10PM +0900, Job Snijders wrote:
> Unless some implementors make significant arguments along the lines of
> "we CANNOT implement this Shutdown Communication functionality, SOLELY
> because of utf8 and lack of representation filtering capabilities", i'd
> water down the utf8 requirement to 7bit ascii (because in the end its
> better to have 'something' than nothing). Another line of argumentation
> against utf8 would be if major security concerns are articulated.

In general, IESG comments will push any user-displayable string to UTF-8
anyway, so I wouldn't stress over this being the requirement.  It's pretty
much an IETF-wide expectation these days.

I think your doc is the first one that I've seen bothering to cite the
unicode considerations documents.  Ideally that'd be a pointer to somewhere
else in a single ref, but I don't think I've seen such an IETF document.

> I hope to capture in the draft that an implementation can choose which
> characters of the Shutdown Communication they represent in the syslog or
> 'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> all newline/newpage/newfeed/newparagraph style chars and make sure that
> the Communication is represented on a single line. I don't have the
> proper words for the draft to express that (yet).

Again, perhaps too much to tackle in this document.

A portion of what you're interested in is covered under the control
characters section:

https://en.wikipedia.org/wiki/Unicode_control_characters

If you try to get too normative you're going to spend a huge amount of text
trying to close all of the holes.

> Also I don't mind if an implementation consciously chooses to only
> represent 7bit ASCII. That should be an implementor decision. They can
> upgrade later. In theory the protocol spec shouldn't be delayed or
> obstructed due to an implementor's current internationalisation
> capabilities (which can change over time).

ASCII is conformant UTF-8, which is one of the nice properties about that
encoding.  What tends to be problematic in many people's implementations is
emitting Latin-1 or similar encodings that are 8-bit as if they're valid
UTF-8, which they're not.

The better question is what the general expected behavior is when things
cannot be displayed.  Some of that will depend on the i18n capabilities of
someone's implementation.


-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Sander Steffann]

Hi Job,

> From an operational perspective it is really useful if you can drop a
> line in the peer's syslog which covers why you shutdown a BGP session.

Very useful indeed, this would be a very welcome feature!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Greg Hankins]

I like the idea, and I think it solves an immediate network operator problem.
I also like the concept of keeping it simple.  

There are a few ongoing efforts to standardize maintenance
notificatications[1], so I suggest that the format and content of the
message be explicitly noted as out of scope and left to the operator.
Though there shouldn't be anything to prevent the operator from using a
common maintenance notification format.

Greg

[1] This one comes to mind:
https://www.peering-forum.eu/system/documents/40/original/20150923_1000_barry_odonmovan_EPF10-INEX-B_ODonovan-MaintenanceNotifications_final.pdf
https://www.maintenancemanager.org/

-- 
Greg Hankins 

-Original Message-
Date: Wed, 16 Nov 2016 15:15:56 +0900
From: Job Snijders 
To: grow@ietf.org, i...@ietf.org
Subject: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's
syslog at shutdown

Hi GROW,

>From an operational perspective it is really useful if you can drop a
line in the peer's syslog which covers why you shutdown a BGP session.
A common use case is to provide a reference between the shutdown event
and an emailed maintenance notification, or maybe you want to make an
emotional statement.

Fictional IOS example:

o00.frnkge02.de.bb#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
o00.frnkge02.de.bb(config)#router bgp 65001
o00.frnkge02.de.bb(config-router)#neighbor 129.250.6.5 shutdown 
"Maintenance [V-NOC-248244242] software upgrade o00.frnkge02.de.bb"

Fictional OpenBGPD example:

[job@kiera ~]$ bgpctl neighbor down AS15562_scarlett_IPv6 "I hate you, 
depeered"
request processed
[job@kiera ~]$

In the above examples, the other side might find something like this in
their logs:

Nov 16 00:20:41 frankfurt-router 589711: RP/0/RSP0/CPU0:Nov 16 
00:20:41.653 : bgp[1059]: %ROUTING-BGP-5-ADJCHANGE : neighbor X.Y.Z.A Down - 
Peer closing down the session (VRF: default) (AS: 35994) (Shutdown 
Communication: "Maintenance [V-NOC-248244242] software upgrade 
o00.frnkge02.de.bb")

or perhaps:

Nov 16 06:59:50 herpaderp bgpd[99938]: neighbor 165.254.255.1 
(AS15562_scarlett_IPv4): received notification: Cease, shutdown communication: 
"I hate you, depeered"

Some might wonder, why "Cease"?

The beauty of using a new Cease subcode, is that the NOTIFICATION
message type already allows extra data to be attached, so for most
implementations it will be very simple to bolt what is specified in
draft-snijders-idr-shutdown-00 on top of their existing code. In some
cases we are looking at just a handful of lines.

Out of all the moments in the lifecycle of BGP interactions, I believe
that the 'shutdown' moment is the most critical one to decorate with
some freeform text. This is low hanging fruit and as should be treated
accordingly. There other moments where one might want to chat with the
neighbor, but those are out of scope for this document, you can always
call or email them!

Previous attempts such as draft-ietf-idr-advisory-00 and
draft-ietf-idr-operational-message-00 failed to deliver for various
reasons (feature creep comes to mind), therefore we are trying to do
this as simple as possible. 

Kind regards,

Job


- Forwarded message from internet-dra...@ietf.org -

Date: Tue, 15 Nov 2016 21:30:15 -0800
From: internet-dra...@ietf.org
To: Jakob Heitz , Job Snijders , John Scudder 

Subject: New Version Notification for draft-snijders-idr-shutdown-00.txt

A new version of I-D, draft-snijders-idr-shutdown-00.txt
has been successfully submitted by Job Snijders and posted to the
IETF repository.

Name:   draft-snijders-idr-shutdown
Revision:   00
Title:  The Shutdown Communication BGP Cease Notification Message 
subcode 
Document date:  2016-11-15
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-snijders-idr-shutdown-00.txt
Status: https://datatracker.ietf.org/doc/draft-snijders-idr-shutdown/
Htmlized:   https://tools.ietf.org/html/draft-snijders-idr-shutdown-00


Abstract:
   This document defines the BGP Cease NOTIFICATION message "Shutdown
   Communication" subcode for operators to transmit a short freeform
   message to describe why a BGP session was shutdown.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

- End forwarded message -

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Peter Hessler]

On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
:I hope to capture in the draft that an implementation can choose which
:characters of the Shutdown Communication they represent in the syslog or
:'show bgp neighbor xxx' output. For instance, I'd recommend to squash
:all newline/newpage/newfeed/newparagraph style chars and make sure that
:the Communication is represented on a single line. I don't have the
:proper words for the draft to express that (yet).

I've been thinking about wording for protecting the receiving system
from possible bad input.  I'm not worried about (valid) UTF-8 display
chars, nor about whitespace things.  I am worried about Little Bobby
Tables, though.

We also have to consider that this will be displayed possibly in a Unix
Shell, Windows Shell, Syslog, SQL server, Web Server; and different
chars have different meanings there.

I'm not quite happy with the wording, but I would like something along
these lines added.  Possibly in the Security section, or at the end of
Section #2.


Receiving systems SHOULD filter the message for the intended output
environment and MAY change octets or sequences of octets for their   
local environment.
As the message may be displayed on a command line, stored
in a syslog server, in an SQL database, or even a Web Server different
outputs MAY happen.
Sending systems MUST NOT depend on changes to their
sequences not happening.


(Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
escapes, Javascript/HTML, etc) 


-- 
Taxes, n.:
Of life's two certainties, the only one for which you can get
an extension.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Julian Seifert]

Hi,

I agree with both points. Maybe not use utf8/unicode or reduce to only 
alphanumerics?

I really like the idea of this feature as we experienced that ourselves lately 
when enquiring about a shutdown
session because nobody entered the (announced) maintenance into our system.

So full support,

kind regards,

  Julian
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Gert Doering]

Hi,

On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> Out of all the moments in the lifecycle of BGP interactions, I believe
> that the 'shutdown' moment is the most critical one to decorate with
> some freeform text. This is low hanging fruit and as should be treated
> accordingly. There other moments where one might want to chat with the
> neighbor, but those are out of scope for this document, you can always
> call or email them!

Sounds tremendously useful.

There's rat-holing risks here (like, charset), though.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jon Mitchell]

On 16/11/16 15:15 +0900, Job Snijders wrote:
> Hi GROW,
> 
> >From an operational perspective it is really useful if you can drop a

I agree with this statement, this looks very useful for communicating
ticket information related to maintenance, the document also appears
well written and fairly complete already.

-Jon

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow