Subject: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14

From: "Susan Hares" <[email-masked]>
Date: Tue, 27 May 2014 13:19:07 -0400

Working Group,

This is to begin a 2 week WG LC for
draft-ietf-idr-bgp-gr-notification-02.txt which will end on 6/10/2014.
Please put within your comments:  "support" or "no-support" for WG LC. 

Jeff Haas comments that the most recent changes reflect implementation
experience and some word smithing.  There is also a minor clarification in
the NOTIFICATION message with respect to including a data byte so the
original reason for the event can be propagated.  (See sec. 3.1 in the
diff.)

The abstract is below. 

Sue Hares

----------

Abstract:

   The current BGP Graceful Restart mechanism limits the usage of BGP

   Graceful Restart to BGP protocol messages other than a BGP

   NOTIFICATION message.  This document defines an extension to the BGP

   Graceful Restart that permits the Graceful Restart procedures to be

   performed when the BGP speaker receives a BGP NOTIFICATION Message.

   This document also defines a new BGP NOTIFICATION Cease Error subcode

   to prevent BGP speakers supporting the extension defined in this

   document from performing a Graceful Restart.

---

From: "Chris Hall" <[email-masked]>
Date: Wed, 28 May 2014 12:44:47 +0100

Susan Hares wrote (on Tue 27-May-2014 at 18:19 +0100):
....
> Jeff Haas comments that the most recent changes reflect
> implementation experience and some word smithing.  There is also a
> minor clarification in the NOTIFICATION message with respect to
> including a data byte so the original reason for the event can be
> propagated.  (See sec. 3.1 in the diff.)

I discovered that draft-00 invented the 'N' bit in the "Flags for
Address Family" and draft-01 un-invented it.  When this goes forward
as an RFC, is this (still-born) 'N' bit then forever deprecated ?  [I
looked at this and could not, for the life of me, remember an 'N' bit
in RFC4724 :-(]

I note that Section 3.1 says:

  "When sending a Hard Reset, the data portion of the NOTIFICATION
   message MUST be used to indicate the reason for the hard reset.  
   The reason is encoded using a standard BGP Cease error subcode
   and MAY also include any relevant data subsequent to the
   subcode."

which rather limits what can be indicated... if (say) an UPDATE
Message Error (Code=3), Attribute Length Error (Subcode=5) is (for
whatever reason) to be sent as a Hard Error, then the reason gets
rather lost ?

Why not treat the Hard Reset Code=6 Subcode=9 as a two octet prefix on
the complete original NOTIFICATION message ?

I note, in passing, that the Hard Reset is intended for consenting
speakers ("Graceful Notification flag has been exchanged") but there
is an absence of MUST.

I assume it is deliberate that the sender of an 'N' flag does not have
to receive one before it MUST follow the rules of Section 4.1 on
receipt of a NOTIFICATION (other than a Hard Reset) ?  (It seems that
the main effect of receiving an 'N' flag is that the receiver no
longer needs to suppress any urge to send a NOTIFICATION, in those
cases where triggering a Graceful Restart is considered far more
useful than the small amount of information a NOTIFICATION would
carry.)

Chris

[I guess it's all too late now... but a new "Hard Error" Code (Code=7)
would avoid getting tangled up with RFC4486, and could be defined to
be a one octet prefix for the original NOTIFICATION ?
Alternatively... the "Hard Bit" could be encoded as the MS-Bit of the
Code octet ?  I guess that was considered and rejected as requiring
too much IANA paperwork ?  Or is there an argument that (other)
systems handling NOTIFICATIONs are more likely to be tolerant of
new/unknown Subcodes than they are of new/unknown Codes ?  In which
case... the "Hard Bit" could be encoded as the MS bit of the Subcode
?]