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

["John G. Scudder" <[e-mail]>]

A couple of responses below As for the rest, I either agree or anyway don't disagree, and will try to take the comments on board.

On Jun 16, 2014, at 10:43 AM, <[e-mail]> <[e-mail]> wrote:
> -----------------------  
> 3) 
> 	"  Flags for Address Family:
> 
> 	            This field contains bit flags relating to routes that were
> 	            advertised with the given AFI and SAFI.
> 
> 	                0 1 2 3 4 5 6 7
> 	               +-+-+-+-+-+-+-+-+
> 	               |F|N| Reserved  |
> 	               +-+-+-+-+-+-+-+-+
> 
> 	   The usage of second most significant bit "N" is deprecated.  This bit
> 	   MUST be advertised as 0 and MUST be ignored upon receipt."
> 
> 
> 
> IMHO the above text could be deleted from the document. (IINM, this flag "N" has been tentatively defined in earlier version of _this_ draft. When this docs becomes RFC, there is nothing the deprecate has this flag would have never been specified)

Given that an earlier version was published that proposed the use of this flag, I see no downside to marking it deprecated now, just in case someone did implement that version or somehow happens upon it. Do you see any reason to remove it, other than orderliness? Bear in mind that "deprecated" means "can eventually be reused".

> -----------------------
> § 4. Operation
> 	"   A BGP speaker that is willing to receive and send BGP NOTIFICATION
> 	   messages in Graceful mode MUST advertise the BGP Graceful
> 	   Notification Flag "N" using the Graceful Restart Capability as
> 	   defined in [RFC4724].
> 
>    When such a BGP Speaker receives a BGP NOTIFICATION message other
>    than a Hard Reset, it MUST follow the rules for the Receiving Speaker
>    mentioned in Section 4.1."
> 
> 
> Between both sentences, IMHO a text is missing stating that this new behavior is only activated when both speakers advertised flag "N". With current second sentence, only the sending of this N flag would be enough to trigger the new behavior.

Do you see some advantage to requiring that the sender has sent the N flag, before you process a graceful notification? I can see some advantage to NOT so requiring, for example it allows you to enable support without having to re-exchange Capabilities. This does call into question why we even need the Capability flag, though I think things are still tidier if we have it.

--John