Subject: [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to 1/31/2017)

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jan 2017 16:04:18 -0500

This begins a 2 week WG Last Call for draft-ietf-idr-shutdown-02.txt
(1/17/2017 to 1/31/2017).  Section 7 of this document lists the
implementations that have been created for this BGP functionality.   These
include: ExaBGP, pmacct, OpenBGPD, Wireshark (packet analyzer), and tcpdump

   o  ExaBGP [1
<https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-1> ]
   o  pmacct [2
<https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-2> ]
   o  OpenBGPD [3
<https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-3> ]
   o  Wireshark [4
<https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-4> ] (packet
analyser)
.         tcpdump [5
<https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-5> ], (alt) [6
<https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-6> ] (packet
analyser)

Operators should examine if freeform UTF-8 encoded string as described meets
their operational needs.  

Sue Hares

WG Co-chair

---

From: Sander Steffann <[email-masked]>
Date: Tue, 17 Jan 2017 23:27:34 +0100

Hi,

> Op 17 jan. 2017, om 22:04 heeft Susan Hares <[email-masked]> het volgende geschreven:
> 
> This begins a 2 week WG Last Call for draft-ietf-idr-shutdown-02.txt (1/17/2017 to 1/31/2017).  Section 7 of this document lists the implementations that have been created for this BGP functionality.   These include: ExaBGP, pmacct, OpenBGPD, Wireshark (packet analyzer), and tcpdump
> 
>    o  ExaBGP [1]
>    o  pmacct [2]
>    o  OpenBGPD [3]
>    o  Wireshark [4] (packet analyser)
> ·         tcpdump [5], (alt) [6] (packet analyser)
> 
> Operators should examine if freeform UTF-8 encoded string as described meets their operational needs.

Speaking as an operator: it does. Adding freeform text to NOTIFICATION messages with code "Cease" with subcode "Administrative Shutdown" would be very useful to tell the operator on the other end of the connection what is going on. Trying to define all the possible values would be impossible because of the huge variety of ways operators work together, and limiting the possible values would limit the usefulness. Freeform text is therefore appropriate at this time, and UTF-8 encoding will allow us to write messages in a language appropriate to the situation.

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 18 Jan 2017 11:36:43 +0000

Susan Hares wrote:
> implementations that have been created for this BGP functionality.  
> These include: ExaBGP, pmacct, OpenBGPD, Wireshark (packet analyzer),
> and tcpdump

definitely support.  This is really useful from an operational point of
view.

> meets their operational needs.  

yes, UTF8 is a sensible choice here.

Nick

---

From: Fredrik Korsbäck <[email-masked]>
Date: Wed, 18 Jan 2017 20:38:28 +0100

On 17/01/17 22:04, Susan Hares wrote:
>    o  ExaBGP [1 <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-1>]
> 
>    o  pmacct [2 <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-2>]
> 
>    o  OpenBGPD [3 <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-3>]
> 
>    o  Wireshark [4 <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-4>] (packet analyser)
> 
> ·         tcpdump [5 <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-5>], (alt) [6 <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-6>] (packet analyser)
> 
>  
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

Full support from my corner aswell (as2603 / as1653). This would greatly benefit us when doing a planned maintenance for example and be able to send out notifications to all connected partners with our public ticketnumber, a describing text and a end-time. Freeform UTF-8 is a perfect fit for this aswell so please keep that in.

A big kudos aswell to the opensource community to get this in quickly. Now i need to go back and convince both Juniper and Arista which is my weapons of choice that this should get in there aswell so we can have a firm implementation of this across the board within the year.

-- 
Fredrik "hugge" Korsbäck

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 18 Jan 2017 22:54:19 +0100

Hello,

On 17 Jan 2017, at 22:04, Susan Hares wrote:

> These

I did the openbgpd implementation of draft-ietf-idr-shutdown. Please 
find my
implementation report below.

A functional description of the implementation can be found at
http://marc.info/?l=openbsd-tech&m=148390348126153&w=2 . Note that the 
final
version of the patch is a few mails down in that thread (and phessler@ 
did some
last whitespace fixes before committing it to OpenBSD CVS). In short, 
the
openbgpd implementation is complete; it can send shutdown communications 
from
the config file and from the command line; it logs received 
communications to
syslog and exposes them in various forms of 'bgpctl .. show'.

During implementation, I have found the draft very clear to read, and 
there were
no ambiguities in how an implementation was supposed to work. In every 
one of
the few situations I had doubts arising from interoperability testing 
with other
fresh implementations, it turned out there was a bug in the other 
implementation
and each time this was quickly corrected on the other side after a 
closer
reading of the draft or the involved code.

Implementation took a few evenings, spread out over weeks, showing that 
the
cognitive load involved with understanding this draft is quite low.

Development was done on OpenBSD 6.0 (as openbgpd has not been ported to 
other
platforms). The work was divided in logical pieces (log incoming 
messages;
remember them for bgpctl show; send them from bgpctl neighbor X down 
REASON;
send them from the configuration file on a reload+refresh).

Interoperability was continuously tested against the then-current
implementations of -shutdown in exabgp and pmacct pmbgpd, running on a 
nearby
Linux VM, as at that time pmacct only had support for sending a shutdown
message, and exabgp was only able to receive shutdown messages. Various 
minor
bugs in the exabgp and pmacct implementations surfaced and were fixed 
during
this process.

Unprintable characters (both of the 'control' and the 'UTF-8' nature) 
were
easily dealt with via the vis(3) (http://man.openbsd.org/vis.3) facility
available on all BSDs, in octal mode as is also used in C string 
constants.
Incidentally Debian has a 'libbsd' that provides it. A standalone 
implementation
would not be hard to do either. vis-encoded strings can be decoded by 
'unvis' on
the commandline, or by simply pasting them into a Python interpreter. 
This way
full Unicode support is achieved without having to worry about 'what 
encoding is
syslog actually in'.

As an example, the Unicode unicorn (U+1F984), encoded on the wire in 
UTF-8 (as
the draft specifies), yields a syslog message such as

     neighbor 165.254.255.26: received shutdown reason: 
"\360\237\246\204"

Running

     echo "\360\237\246\204" | unvis

on an UTF-8 capable terminal, or typing

     print("\360\237\246\204".decode('utf-8'))

into a Python2 prompt, will recover said unicorn. 🦄

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Job Snijders <[email-masked]>
Date: Wed, 18 Jan 2017 23:28:49 +0100

Dear Peter,

On Wed, Jan 18, 2017 at 10:54:19PM +0100, Peter van Dijk wrote:
> I did the openbgpd implementation of draft-ietf-idr-shutdown. Please find my
> http://marc.info/?l=openbsd-tech&m=148390348126153&w=2 . Note that the final
> version of the patch is a few mails down in that thread (and phessler@ did
> some last whitespace fixes before committing it to OpenBSD CVS). In short, the
> openbgpd implementation is complete; it can send shutdown communications from
> the config file and from the command line; it logs received communications to
> During implementation, I have found the draft very clear to read, and there
> were no ambiguities in how an implementation was supposed to work. In every
> one of the few situations I had doubts arising from interoperability testing
> with other fresh implementations, it turned out there was a bug in the other
> implementation and each time this was quickly corrected on the other side
> after a closer reading of the draft or the involved code.
> 
> Implementation took a few evenings, spread out over weeks, showing that the
> Development was done on OpenBSD 6.0 (as openbgpd has not been ported to other
> platforms). The work was divided in logical pieces (log incoming messages;
> remember them for bgpctl show; send them from bgpctl neighbor X down REASON;
> implementations of -shutdown in exabgp and pmacct pmbgpd, running on a nearby
> message, and exabgp was only able to receive shutdown messages. Various minor
> bugs in the exabgp and pmacct implementations surfaced and were fixed during
> this process.
> 
> Unprintable characters (both of the 'control' and the 'UTF-8' nature) were
> available on all BSDs, in octal mode as is also used in C string constants.
> implementation would not be hard to do either. vis-encoded strings can be
> decoded by 'unvis' on the commandline, or by simply pasting them into a Python
> interpreter. This way full Unicode support is achieved without having to worry
> about 'what encoding is syslog actually in'.
> 
> As an example, the Unicode unicorn (U+1F984), encoded on the wire in UTF-8 (as
>     neighbor 165.254.255.26: received shutdown reason: "\360\237\246\204"
> 
> Running
> 

Thank you for this write-up!

Kind regards,

Job

---

From: Teun Vink <[email-masked]>
Date: Thu, 19 Jan 2017 09:15:14 +0100

> meets their operational needs.  

Full support here, I really hope this will become a truly accepted and
implemented operational standard and that it will reduce the number of
"hey I see a peering session drop" mails and calls we have to deal with
after every maintenance. 

UTF-8 sounds like a sane choice for string encoding.

Best regards,
-- 
Teun Vink
BIT           | [email-masked]     | +31 318 648 688
KvK: 09090351 | GPG: 0x5A04F4E2 | RIPE: TEUN-RIPE

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Thu, 19 Jan 2017 10:39:38 +0100

Hello,

On 01/17/2017 10:04 PM, Susan Hares wrote:
> <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-1>]
>    o  pmacct [2
> <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-2>]
>    o  OpenBGPD [3
> <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-3>]
>    o  Wireshark [4
> <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-4>]
> (packet analyser)
> ·         tcpdump [5
> <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-5>], (alt)
> [6 <https://tools.ietf.org/html/draft-ietf-idr-shutdown-02#ref-6>]
> (packet analyser)
>
>  
>

I hope this will help to significantly reduce the amount of unnecessary
e-mails about missed maintenance tickets coming up on the various IXP
mailing lists over the next couple of years. UTF-8 freeform will allow
operators to change the format to whatever is needed for the use-case,
future-proofing the standard.

Best regards,
Martijn Schmidt
i3D.net / AS49544

---

From: Tom Hodgson <[email-masked]>
Date: Thu, 19 Jan 2017 17:20:28 +0000

Hi,

>  [snip] 

Support this as a useful tool, especially for networks who have not progressed fully down the full automation path yet and have to rely on manual view and intervention of session events. With operator hat on UTF8 seems sensible.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 27 Jan 2017 16:38:33 -0500

Sue and authors,

> include: ExaBGP, pmacct, OpenBGPD, Wireshark (packet analyzer), and tcpdump

While working through the likely changes in our BGP implementation, the
following thought occurred while looking at the relevant RFC 4486 sub-codes
and triggers.

RFC 4486 defines two administrative actions that seem applicable to this
draft:

         2        Administrative Shutdown
         4        Administrative Reset

The draft covers code point 2.

I believe the draft should cover both administrative sub-codes.  It also
permits two slightly different work flows:

run clear bgp neighbor 192.0.2.1 reason "You have a bgp wedgie and I'm trying to clear it"

set protocols bgp group external neighbor 192.0.2.1 shutdown reason "De-peered with prejudice"

The first allows a reset reason to be passed along that may be transient.

The second permits a reason to persist in subsequent attempts when that BGP
speaker tries to re-connect.

Beyond the above point, I find the document to be of good quality.

-- Jeff

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Jan 2017 16:48:20 -0500

On Tue, Jan 17, 2017 at 4:04 PM, Susan Hares <[email-masked]> wrote:
> (1/17/2017 to 1/31/2017).

Support -- willing to edit, review, comment, fold, spindle or mutilate.

> Section 7 of this document lists the

Yup. I'd prefer freeform straight ASCII, but I understand (and am ok
with) the UTF-8 rationale.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Matthew Walster <[email-masked]>
Date: Fri, 27 Jan 2017 15:21:19 -0800

On 27 January 2017 at 13:38, Jeffrey Haas <[email-masked]> wrote:

> I believe the draft should cover both administrative sub-codes.

​While I'm hesitant to consider this a perfect idea due to the fact that
there are mechanisms within BGP to make this a non-disrupting event not in
such explicit need of notification​ similar to a shut down event, such as
graceful restart, end-of-rib markers etc, there is the possibility of a
reset occurring and the BGP session not restoring as intended with a
notification from the remote side or indeed a TCP reset should the speaker
not be willing/ready to accept the new connection. At which point, it would
be good to have the shut down communication message to reference the
intended action, reference a contact point etc.

I'd support a widening of the draft to include the additional code point
(Cease/Administrative Shutdown and Cease/Administrative Reset).

Indeed, could not all Cease sub-codes use this method? For instance:

         1        Maximum Number of Prefixes Reached

The notification could provide a link to a filter update site, or an email
address for the NOC to take further actions... Or to indicate whether or
not the connection is moved into an error state with no future connections
allowed until the error is cleared by an operator.

         3        Peer De-configured

Likewise, this could be supplemented with a message when the session is
being deconfigured and moved to another router.

         6        Other Configuration Change

This has always been difficult to interpret, and has very recently been
something I've been butting up against. A vendor supplied string detailing
the exact change mechanism that caused this would be welcome.

There is obvious scope-creep at this point, I would like to suggest either
the draft considered as-is or to allow all Cease sub-codes to have shutdown
communication possible.

The rest of the draft itself seems well written, easy to understand, and
even unamended would be a welcome addition to the internet operators
toolkit.

Matthew Walster

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 27 Jan 2017 21:02:05 -0500

> > I believe the draft should cover both administrative sub-codes.
[...] Suggestions of other cases to expand the text-form of the notification
to other sub-codes.

> the draft considered as-is or to allow all Cease sub-codes to have shutdown

I certainly hadn't intended to try to push for a more general widening of
the scope; just point out something under the existing use case.

While you give three other examples of places that could benefit from
additional data regarding why the session has been sent a CEASE, I don't
think all of them are equally clear with respect to that data being text.

As an example, the max prefixes might benefit from a simple tuple.  E.g.
AFI,SAFI,<limit>.  Although keeping this within even a light-weight TLV
would permit space for the machine-readable portion along with a human
readable one.

I would suggest in the absence of a strong case for text strings in the
other sub-codes that for now the draft stay restricted to the administrative
reset cases.  As this draft proves, if there's consenus to add additional
DATA to one of the code points, it can move fast.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Sat, 28 Jan 2017 13:02:17 +0100

Hi group,

On Fri, Jan 27, 2017 at 09:02:05PM -0500, Jeffrey Haas wrote:
> > > [...] Suggestions of other cases to expand the text-form of the
> > > notification to other sub-codes.
> 
> > There is obvious scope-creep at this point, I would like to suggest
> > either the draft considered as-is or to allow all Cease sub-codes to
> > have shutdown communication possible.
> 
> I certainly hadn't intended to try to push for a more general widening
> of the scope; just point out something under the existing use case.
> 
> additional data regarding why the session has been sent a CEASE, I
> don't think all of them are equally clear with respect to that data
> being text.
> 
> As an example, the max prefixes might benefit from a simple tuple.
> E.g. AFI,SAFI,<limit>. Although keeping this within even a
> light-weight TLV would permit space for the machine-readable portion
> along with a human readable one.
> 
> I would suggest in the absence of a strong case for text strings in
> the other sub-codes that for now the draft stay restricted to the
> administrative reset cases. As this draft proves, if there's consenus
> to add additional DATA to one of the code points, it can move fast.

I think Jeff's suggestion to add the Administrative Reset (subcode 4)
case is a good one. There can be value in attachting contact information
or a case identifier to BGP resets. Matthew mentioned (outside of this
mailing list) that this information would especially be useful if after
the reset, the BGP session does not re-establish. Also, conceptually the
'reset' and 'shutdown' are close to each other as they are initiated by
the Administrator.

However, I consider the other subcodes out of scope for what
draft-ietf-idr-shutdown tries to accomplish, and as such would belong in
their own Internet-Draft.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Sat, 28 Jan 2017 13:10:25 +0100

BTW, regarding last call & IDR implementation requirements, i can
immediately deliver at least two implementations that also accomodate
the 'reset' case so from that perspective there will be no blocker to
proceed.

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 28 Jan 2017 10:35:17 -0500

Job: 

Thanks for letting me know.  Please put up the implementation changes once
you have the reset in a draft.  Without out it, we'd will be blocked to send
this to the IESG.

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Saturday, January 28, 2017 7:10 AM
To: Jeffrey Haas
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to
1/31/2017)

BTW, regarding last call & IDR implementation requirements, i can
immediately deliver at least two implementations that also accomodate the
'reset' case so from that perspective there will be no blocker to proceed.

Kind regards,

Job

On Sat, Jan 28, 2017 at 01:02:17PM +0100, Job Snijders wrote:
> > > There is obvious scope-creep at this point, I would like to 
> > > suggest either the draft considered as-is or to allow all Cease 
> > > sub-codes to have shutdown communication possible.
> > 
> > I certainly hadn't intended to try to push for a more general 
> > widening of the scope; just point out something under the existing use
case.
> > 
> > While you give three other examples of places that could benefit 
> > from additional data regarding why the session has been sent a 
> > CEASE, I don't think all of them are equally clear with respect to 
> > that data being text.
> > 
> > administrative reset cases. As this draft proves, if there's 
> > consenus to add additional DATA to one of the code points, it can move
fast.
> case is a good one. There can be value in attachting contact 
> information or a case identifier to BGP resets. Matthew mentioned 
> (outside of this mailing list) that this information would especially 
> be useful if after the reset, the BGP session does not re-establish. 
> Also, conceptually the 'reset' and 'shutdown' are close to each other 
> as they are initiated by the Administrator.
> 
> draft-ietf-idr-shutdown tries to accomplish, and as such would belong 
> in their own Internet-Draft.
> 
> Kind regards,
> 
> Job