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

From: Job Snijders <[email-masked]>
Date: Wed, 16 Nov 2016 15:15:56 +0900

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 [email-masked] -----

Date: Tue, 15 Nov 2016 21:30:15 -0800
From: [email-masked]
To: Jakob Heitz <[email-masked]>, Job Snijders <[email-masked]>, John Scudder <[email-masked]>
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 -----

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 16 Nov 2016 03:26:24 -0500

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

---

From: Gert Doering <[email-masked]>
Date: Wed, 16 Nov 2016 11:55:35 +0100

Hi,

> neighbor, but those are out of scope for this document, you can always

Sounds tremendously useful.

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

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

SpaceNet AG                        Vorstand: 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

---

From: Julian Seifert <[email-masked]>
Date: Wed, 16 Nov 2016 11:29:28 +0000

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

---

From: [email-masked] (Marco d'Itri)
Date: Wed, 16 Nov 2016 12:38:49 +0100

> I agree with both points. Maybe not use utf8/unicode or reduce to only alphanumerics?
Not supporting UTF-8 is not acceptable for a new IETF protocol and would 
preclude using it in some cultures.

Customers with really crappy management infrastructure could ask their 
vendors to implement a knob to report the strings as base64, but 
I really wonder which real world use cases there are for this.

-- 
ciao,
Marco

---

From: Job Snijders <[email-masked]>
Date: Wed, 16 Nov 2016 22:01:10 +0900

On Wed, Nov 16, 2016 at 12:38:49PM +0100, Marco d'Itri wrote:
> Not supporting UTF-8 is not acceptable for a new IETF protocol and
> would preclude using it in some cultures.
> 
> vendors to implement a knob to report the strings as base64, but I
> really wonder which real world use cases there are for this.

Yes, I can't imagine folks using Cyrillic or Kanji for their daily
communication to be happy if the Shutdown Communication only allows use
of Latin characters.

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.

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

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

Kind regards,

Job

---

From: Peter Hessler <[email-masked]>
Date: Wed, 16 Nov 2016 14:47:07 +0100

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.

---

From: Greg Hankins <[email-masked]>
Date: Wed, 16 Nov 2016 09:54:16 -0500

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 <[email-masked]>

-----Original Message-----
Date: Wed, 16 Nov 2016 15:15:56 +0900
From: Job Snijders <[email-masked]>
To: [email-masked], [email-masked]
Subject: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's
	syslog at shutdown

Hi GROW,

Fictional IOS example:

or perhaps:

Kind regards,

Job

----- Forwarded message from [email-masked] -----

Abstract:

The IETF Secretariat

----- End forwarded message -----

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Nov 2016 16:09:57 +0100

Hi Job,

> 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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 Nov 2016 16:56:58 +0000

> and an emailed maintenance notification, or maybe you want to make an

Can we please adopt this as a WG doc in whatever WG is most appropriate?
 IDR? This looks like a ridiculously useful operational tool.

UTF8 please, considering the extent to which us-ascii does not provide
an adequate character set for a huge percentage of the world's operator
population.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Nov 2016 20:19:45 -0500

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

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

> 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

---

From: Job Snijders <[email-masked]>
Date: Thu, 17 Nov 2016 10:24:28 +0900

> 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

> trying to close all of the holes.

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

> someone's implementation.

I'd just skip over them.

grÃ£Â©gory -> grgory

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Nov 2016 20:36:40 -0500

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

:         2        Administrative Shutdown
:         3        Peer De-configured
:         6        Other Configuration Change

Ones that possibly shouldn't be changed:

:         1        Maximum Number of Prefixes Reached

This one is fully specified.

:         4        Administrative 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.

:         5        Connection 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.

:         7        Connection Collision Resolution
:         8        Out of Resources

I suspect these shouldn't return anything.

> 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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Nov 2016 20:38:18 -0500

> 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

---

From: Job Snijders <[email-masked]>
Date: Thu, 17 Nov 2016 10:42:15 +0900

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Nov 2016 20:47:01 -0500

> 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

---

From: Job Snijders <[email-masked]>
Date: Thu, 17 Nov 2016 10:46:13 +0900

On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> (I'm not exactly concerned about this since it's local in impact but
> you'd think after the discussions this week...)

I learned the lesson: as you can see in the draft the codepoint is
referenced as "TBD". :-) 

If you want to do interop testing ping me offlist and we'll negotiate a
subcode for our locally confined experiment.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 17 Nov 2016 12:06:32 +0900

On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> 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:
> 

> <snipped the codes that aren't suitable for decoration>

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2016 04:27:52 +0100

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.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Nov 2016 13:53:56 +0900

> On Nov 17, 2016, at 12:27 PM, Robert Raszuk <[email-masked]> 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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 17 Nov 2016 06:00:58 +0000

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.

> From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Wednesday, November 16, 2016 5:47 PM
> To: Job Snijders <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
>

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 16:28:50 +0000

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

_________________________________________________________________________________________________________________________

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.

---

From: Job Snijders <[email-masked]>
Date: Fri, 18 Nov 2016 09:45:48 +0900

> 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

---

From: <[email-masked]>
Date: Fri, 18 Nov 2016 08:32:19 +0000

> From: Job Snijders [mailto:[email-masked]]  > Sent: Friday, November 18, 2016 1:46 AM
> 

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

---

From: Job Snijders <[email-masked]>
Date: Fri, 18 Nov 2016 08:45:56 +0000

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, <[email-masked]> wrote:

> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 18 Nov 2016 08:52:12 +0000

Thanks.
--Bruno

From: Job Snijders [mailto:[email-masked]]
Sent: Friday, November 18, 2016 9:46 AM
To: DECRAENE Bruno IMT/OLN
Cc: Jeffrey Haas; Job Snijders; [email-masked]; [email-masked]
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, <[email-masked]<mailto:[email-masked]>> wrote:

> From: Job Snijders [mailto:[email-masked]<mailto:[email-masked]>]  > Sent: Friday, November 18, 2016 1:46 AM
>
 > On Thu, Nov 17, 2016 at 04:28:50PM +0000, [email-masked]<mailto:[email-masked]> wrote:
 > > I support the draft.

Kind regards,
-- Bruno

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 18 Nov 2016 20:01:30 +0000

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, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks.
--Bruno

Cc: Jeffrey Haas; Job Snijders; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Bruno,

Job

Kind regards,
-- Bruno

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Jared Mauch <[email-masked]>
Date: Sat, 19 Nov 2016 07:34:30 -0500

> 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 wa…

	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 [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: "Neil J. McRae" <[email-masked]>
Date: Sat, 19 Nov 2016 13:51:21 +0000

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 <[email-masked]> wrote:
>

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 19 Nov 2016 14:56:15 +0100

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 <[email-masked]> wrote:
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

-- 
Marco

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 15:07:13 +0100

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 <[email-masked]> 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
> >

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 15:00:18 +0100

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 <[email-masked]> 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

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 19 Nov 2016 15:27:51 +0100

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 <[email-masked]> wrote:
> 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 ?
>

-- 
Marco

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 15:30:33 +0100

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 <[email-masked]> wrote:

> reasonable.
> >> >> :characters of the Shutdown Communication they represent in the
> syslog
> >> >> or

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 19 Nov 2016 14:48:00 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 15:57:06 +0100

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 NOTIFICATION MSG is an overkill so do not count of
new proposal from me on it. Operational message solved that already.

Btw how are you going to handle it in IX ? I assume RS peers will not get
any info if one of the parties they used to get routes from goes down and
sends
free form msg to RS ? Routes will be get withdrawn and that's it.

Best,
R.

---

From: "Neil J. McRae" <[email-masked]>
Date: Sat, 19 Nov 2016 14:59:03 +0000

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 <[email-masked]> wrote:
> 
> Robert Raszuk wrote:

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 19 Nov 2016 10:08:13 -0500

> On Nov 19, 2016, at 9:59 AM, Neil J. McRae <[email-masked]> wrote:
> 

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 16:10:00 +0100

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 <[email-masked]> wrote:

> We shouldn't be encouraging folks to build networks that for routine
> events we then require more manual intervention when it's unwarranted.
>
> 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
>

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 19 Nov 2016 10:12:43 -0500

> On Nov 19, 2016, at 10:10 AM, Robert Raszuk <[email-masked]> 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. 
> 

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 16:16:37 +0100

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 prohibit one to send more then one
cease notification message.

One would be subcode 2 as today .. the other would be subcode 9 INFO.

> The shutdown draft requires no changes for any useful backward
compatibility.

If you add length as proposed by Job it does.

> But in order to signal such other information, the routers in question
would need to support Advisory.

Advisory is also not structured.

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

Indeed !!! Is the problem here that one side does not know the email of the
other side and syslog will be the communicator ?

Thx,
R.
​

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 19 Nov 2016 10:31:41 -0500

> On Nov 19, 2016, at 10:16 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Jeff,
> 
> > Part of the motivation I had for suggesting the use of an existing sub-code 
> > It's still "administrative shutdown".  Today, you'd have zero extra information 
> > what it's about.
> 
> ​My interpretation of 4271 does not prohibit one to send more then one cease notification message. 
> 

What would the distinction between admin shutdown (clear) vs. info-read the friendly message be?  

> 
> > The shutdown draft requires no changes for any useful backward compatibility.  
> 

4271, section 6.4.  I'm being a bit of a pain in my interpretation here but simply:
- You still have a valid code and sub-code.  (The admin shutdown subcode is already not in 4271 and thus not in compliance with 4271-only implementation.)
- If you don't understand the data, you can't report it back.
- You're instructed to "bring this to the attention of the administration of the peer".  This is one of the motivators already for the hexdump many implementations use.

I derive my justification from the same used when RFC 4486 was discussed. :-)

> 
> > But in order to signal such other information, the routers in question would need to support Advisory.
> 

Partially my point.  "SMS over BGP" is how someone commented on this previously.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 16:48:37 +0100

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

Thx,
r.

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 19 Nov 2016 10:56:57 -0500

> On Nov 19, 2016, at 10:48 AM, Robert Raszuk <[email-masked]> wrote:
> 
> ​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). 

A change to use a NOTIFICATION message to *NOT* reset the TCP session is a rather large deviation from 4271.

I would not be supportive of that.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 17:07:50 +0100

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.

---

From: Job Snijders <[email-masked]>
Date: Sat, 19 Nov 2016 17:58:14 +0100

> 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

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 19 Nov 2016 17:58:52 +0100

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 <[email-masked]> wrote:
>> 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

-- 
Marco

---

From: "Neil J. McRae" <[email-masked]>
Date: Sat, 19 Nov 2016 17:23:15 +0000

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 <[email-masked]> wrote:
> 
> Robert,
>

---

From: Job Snijders <[email-masked]>
Date: Sat, 19 Nov 2016 20:41:38 +0100

On Sat, Nov 19, 2016 at 05:23:15PM +0000, 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

---

From: "Neil J. McRae" <[email-masked]>
Date: Sat, 19 Nov 2016 20:26:25 +0000

I just wish I thought we had the luxury of lazy operations like this!

Neil 

> On 19 Nov 2016, at 19:41, Job Snijders <[email-masked]> wrote:
>

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 19 Nov 2016 21:16:30 +0000

> 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

---

From: Job Snijders <[email-masked]>
Date: Sat, 19 Nov 2016 22:28:53 +0100

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 <[email-masked]> wrote:
> 
> Neil J. McRae wrote:

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 19 Nov 2016 21:58:03 +0000

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 23:09:27 +0100

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.

---

From: Job Snijders <[email-masked]>
Date: Sun, 20 Nov 2016 10:54:59 +0100

On Sat, Nov 19, 2016 at 11:09:27PM +0100, Robert Raszuk wrote:
> 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.

Hypothetical operators come in all shapes and sizes, but we've had a
show of hands here from a set of actual operators who find this
functionality useful in their daily workflow, and expect their peers
would as well. 

There is a wide range of scenarios that are addressed by the proposal in
it's current form, including:
    
    * An engineer actively troubleshooting a router connected to a large
    Internet Exchange wishing to tell the rest of the peers a human is
    on it (and avoid the mail flood of "you're flapping!")

    * An automated system "enriching" the session termination with ticket
    related metadata to allow a user exploring a log to find context
    
    * A set of default messages that could be implemented by a vendor
    depending on which cli command triggered the shutdown to
    transparently enrich the remote side with information
    
It is essentially an incarnation of the old 'wall' command from UNIX,
with users substituted by peers, and the delivery mechanism being BGP.
The aim is to enable an inter-domain version of:

    # echo "brb, kernel update" | wall

Nothing more.
    
Any implications on screenscrapping are an artifact of implementation,
and vendors seeking a consistent machine-parsable CLI can send the
message directly into the log instead of modifying the output of a CLI
status description command. JunOS is a good example of how
screenscraping can be avoided with their "| output xml" feature.
Shutdown will be just another leaf in such XML output.

This proposal does not aim to solve all challenges of inter-domain
operations orchestration, but to specifically provide a tool to annotate
an unexpected event to ease the triaging process by a human operator. 

In its current form, it provides an ideal fit for this purpose, while
leaving enough flexibility to experiment with structured communications
for those who intend to use BGP for general inter-domain operations
orchestration signaling.

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

We're updating 4486, please try to keep up.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Sun, 20 Nov 2016 11:09:15 +0100

> and do not accept any suggestions.

No, we are just selective in which suggestions we accept. Suggestions
falling short of the mark are countered and discarded.

> enable better automated interpretation of the message I think there is
> more problems here.

This proposal aims to accomplish a simple thing, which is to enrich an
event with additional contextual information and assist in triaging
("This is unexpected, is this a problem?" "Should we embark on a
specific procedure?") in an operator-centric workflow. By keeping it
free form, it allows enough space to experiment with structured
inter-domain signaling, and if operators find this useful a dictionary
of messages can be offered at a later date as an extension based on
operational experience.

It is absolutely is not aiming to act as a generic inter-domain
signaling protocol for operations orchestration.

> TLV within current NOTIFICATION MSG is an overkill so do not count of
> new proposal from me on it. 

Hence this is not TLV, this is LV, already explained here:
https://www.ietf.org/mail-archive/web/idr/current/msg17127.html

> Operational message solved that already.

Operational message expired in September 2012, and as such I do not
consider it an active working group document anymore.

The Operational message does not provide a strong correlation between a
Cease event and some type of additional meta-data. Same reason why
'advisory' and 'shutdown' do not preclude each other.

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

> Btw how are you going to handle it in IX ? I assume RS peers will not
> get any info if one of the parties they used to get routes from goes
> down and sends free form msg to RS ? Routes will be get withdrawn and
> that's it.

Correct. This is the expected behaviour.

Kind regards,

Job

---

From: Gert Doering <[email-masked]>
Date: Sun, 20 Nov 2016 15:14:02 +0100

Hi,

> Correct. This is the expected behaviour.

... and the IXP is, of course, free to have a looking glass type web 
page where the last "shutdown info message" the RS received can be
displayed.  So it's useful in IXP context, even if not directly visible
to other RS peers.

Gert Doering
        -- NetMaster

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Sun, 20 Nov 2016 18:34:56 +0000

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

---

From: "Neil J. McRae" <[email-masked]>
Date: Sun, 20 Nov 2016 20:02:21 +0000

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 <[email-masked]> wrote:
>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 20 Nov 2016 23:09:25 +0100

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Nov 2016 00:10:36 +0100

I am not suggesting TLV format. Just few  optional and predefind keywords
for those who like your peer to be able to parse it.

I am not taking away anything you are proposing just adding few words which
can help.

What is the problem of accepting it ?

Thx
R.

On Nov 20, 2016 21:02, "Neil J. McRae" <[email-masked]> 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.

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!)

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Nov 2016 00:21:32 +0100

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

---

From: Sam Silvester <[email-masked]>
Date: Mon, 21 Nov 2016 16:19:48 +1030

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

> 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

---

From: joel jaeggli <[email-masked]>
Date: Mon, 21 Nov 2016 00:22:28 -0800

On 11/20/16 3:21 PM, Robert Raszuk wrote:
> 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.

---

From: Peter Hessler <[email-masked]>
Date: Mon, 21 Nov 2016 10:03:35 +0100

On 2016 Nov 19 (Sat) at 20:26:25 +0000 (+0000), Neil J. McRae wrote:
:I just wish I thought we had the luxury of lazy operations like this!
:

I have about 4 peers where they have exactly this kind of lazy
operators.  Some of them are big enough to know better.

I want this, because they at least look at the "show neighbor" output
before freaking out and spamming all of our support contacts.

:Neil 
:
:> On 19 Nov 2016, at 19:41, Job Snijders <[email-masked]> wrote:
:> 
:>> On Sat, Nov 19, 2016 at 05:23:15PM +0000, 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

-- 
It's bad luck to be superstitious.
		-- Andrew W. Mathis

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 21 Nov 2016 17:18:46 -0500

> 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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 22 Nov 2016 20:58:22 +0000

Reasons to do this:
1. A bunch of people want it.
2. It's an easy feature to implement.
3. It impacts nothing else.

Remember, it's already a free form data field. 
We can put anything into it we like.

If you want a TLV, no big deal.
The first "T" is a UTF8 string.
Feel free to write drafts for other "T"s.

Thanks,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 22 Nov 2016 22:04:49 +0000

I was reminded that the data field already exists and some people may be using it.
Putting a human readable string into it should be fine.
If someone puts something else, then the result is just Jibberish,
but not harmful. OTOH, TLVs could get tricky.
If we want to use TLVs, another NOTIFICATION sub code might be wise.

(I wonder where Jibber is and whether we should hold an IETF meeting there)

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
> Sent: Tuesday, November 22, 2016 12:58 PM
> To: [email-masked]; [email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Nov 2016 17:09:15 -0500

> On Nov 22, 2016, at 5:04 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> but not harmful.

Minimal sanitizing of the string to make sure it's a valid utf-8 is still necessary, or at least that your printf equivalent doesn't barf on malformed utf-8.

> OTOH, TLVs could get tricky.

No worse than malformed utf-8.

> (I wonder where Jibber is and whether we should hold an IETF meeting there)

Probably should refer the question to the mtgvenue WG. 

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Nov 2016 11:31:37 -0800

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

randy

---

From: joel jaeggli <[email-masked]>
Date: Tue, 29 Nov 2016 12:12:17 -0800

> 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