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

[Robert Raszuk <[e-mail]>]

Job,

To recap ...

RFC4271 says:

      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    | Error subcode |   Data (variable)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


...


Note that the length of the Data field can be determined from
         the message Length field by the formula:

                  Message Length = 21 + Data Length


RFC4486 says:

   If a BGP speaker decides to administratively shut down its peering
   with a neighbor, then the speaker SHOULD send a NOTIFICATION message
   with the Error Code Cease and the Error Subcode "Administrative
   Shutdown".



That all means there is no guarantee that if you insert length some CPEs

will not crush even if the length value will be all 0.


That means that in my network where there is 15000 CEs if at least one

crashes I can not upgrade any longer any PE OS which may be needed for

other reasons.


That would be pretty bad effect of the proposed enhancement.


If we are to continue to use subcode 2 let's stay with current 4271 format

and not update 4271 RFC with this proposal.


Or let's define new cease subcode say "INFO" which will be injected only when

operator types in a string. That way existing deployments are safe and you can

enjoy new communication channel (hopefully with some well defined keywords :).


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
>