Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Jakob Heitz (jheitz)]

I support 

Thanks,
Jakob.

> On Nov 16, 2016, at 12:03 PM, Christopher Morrow 
>  wrote:
> 
> Howdy gentle folk,
> Let's take a few minutes to discuss and digest whether or not the subject 
> draft with abstract:
>   Examples and inspiration for operators on how to use Large BGP
>Communities.
> 
> should be adopted as a WG draft in GROW. This call ends 12/6/2016 or December 
> 6, 2016.
> 
> thanks!
> -chris
> co-chair
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
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