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

[Jesper Skriver <[e-mail]>]

On Sat, Nov 19, 2016 at 12:24:51PM +0100, Robert Raszuk wrote:
> ​Hi,
> 
> The alternative to the below which could be attractive both to senders and
> receivers is indirection ... meaning that we would only extend current
> cease sub 2 with say 21 octets which would be basic UTF8 string of URL
> shortcut: *https://goo.gl/V5as9h <https://goo.gl/V5as9h>*

That seems to raise the bar for using it significantly, it require
more work if I first have to setup a page somewhere, generate a
short URL for it, and then type the URL into my router when doing

neighbor FOO shutdown http://some.url

versus

neighbor FOO shutdown "having issues, ETA 05:00"

/Jesper

> ​That way anyone receiving the link in the cease admin down or any other
> sub type can click on it and read any arbitrary info or even get guide how
> to configure his peer to say support new peering types being currently
> prepared for cooking.
> 
> Cheers,
> R.
> 
> On Sat, Nov 19, 2016 at 11:32 AM, Job Snijders <[e-mail]> wrote:
> 
> > Hi Jakob, Working group,
> >
> > It is for "defensive" purposes: what if utf8 turns out to be terrible,
> > then cease subcode 2 can still be used but we can put something else in
> > the datafield trailing the subcode.
> >
> > the advantage of using a length field is that we avoid discussing types
> > and semantics, but future protocol developers have an option to use the
> > trailing data in the NOTIFICATION message for some purpose.
> >
> > It would look like this:
> >
> > -----
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Error code 6  |   Subcode 2   |    Length     |     ...       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                   ... Shutdown Communication ...              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                              ...                              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Length:
> >         The Length value can range from 0 to 128 and indicates how many
> >         bytes of UTF-8 for the Shutdown Communication follow. If the
> >         length field is set to 0, no UTF-8 bytes follow.
> >
> > -----
> >
> > This is an very lightweight approach to leave the door somewhat open ,
> > should the need to do something else with the trailing data arise, and
> > it only costs 1 byte.
> >
> > Kind regards,
> >
> > Job
> >
> >
> > On Fri, Nov 18, 2016 at 08:01:30PM +0000, 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.
> > >
> > > Thanks,
> > > Jakob.
> > >
> > > On Nov 18, 2016, at 12:52 AM,
> > > <[e-mail]<mailto:[e-mail]>> wrote:
> > >
> > > Thanks.
> > > --Bruno
> > >
> > > From: Job Snijders [mailto:[e-mail]]
> > > Sent: Friday, November 18, 2016 9:46 AM
> > > To: DECRAENE Bruno IMT/OLN
> > > Cc: Jeffrey Haas; Job Snijders; [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>
> > > 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, <[e-mail]<mailto:
> > [e-mail]>> wrote:
> > >
> > >
> > > > From: Job Snijders [mailto:[e-mail]<mailto:[e-mail]>]
> > > Sent: Friday, November 18, 2016 1:46 AM
> > > >
> > >  > On Thu, Nov 17, 2016 at 04:28:50PM +0000, [e-mail]<
> > mailto:[e-mail]> 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
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >

> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr


/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.