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

[<[e-mail]>]

Hi,

Read and support.

1)
"1. Introduction
[...]
This is also true for HOLDTIME expiration"

IMHO this is a significant point that could be added in the Abstract.
e.g.

OLD:  when the BGP speaker receives a BGP NOTIFICATION Message

NEW: when the BGP speaker receives a BGP NOTIFICATION Message or the HOLDTIME expires.


In particular, if the BGP speaker is down, the upper bound to keep BGP routes is increased. IHMO this should be indicated in a new deployment consideration section.
Also it's not very clear how long the routes are kept. I guess HOLDTIME + "the possible local unnamed timer at the end of RFC 4724 section 4.2". If this is a case, this timer should probably be given an name and become a MUST to implement (it's a MAY in RFC 4271)
--

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)

--
§ 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<http://tools.ietf.org/html/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<http://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-03#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.

§4.1  Rules for the Receiving Speaker
I don't find particularly easy to red no clear this section 4.1 which is trying to patch section 4.2 of RFC4274.

e.g. " As part of this extension, routes from the peer previously marked as
   stale MUST NOT be deleted, until and unless the timer mentioned in
   the final paragraph of [RFC4724<http://tools.ietf.org/html/rfc4724>] S. 4.2 expires, or unless a Hard
   Reset is performed. »

- So the STALE routes are not deleted when I received an End-of-RIB marker?? (I know the answer but it's not crystal clear what exactly the above sentence overwrite)
As an alternative, the whole RFC 4724 s4.2 could be copied and updated as needed. Or the OLD/NEW deliminater could be used to indicate what is removed and what is added.

- Also it's not clear whether these modifications only apply to GR triggered by NOTIFICATION/HOLDTIME expiration or by "regular" (RFC 4274) GR cases.
---
Nits (IMHO) :



OLD: If a Hard Reset is used, a full session reset is performed.

NEW: If a Hard Reset is used, a session reset is performed as per RFC 4271.


OLD:   A new BGP NOTIFICATION Cease message subcode is defined known as the BGP Hard Reset Subcode.
NEW: A new BGP NOTIFICATION Cease message subcode called "BGP Hard Reset Subcode" is defined.

Thanks,
Best regards,
Bruno

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, May 27, 2014 7:19 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14

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.



_________________________________________________________________________________________________________________________

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.