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

From: <[email-masked]>
Date: Mon, 16 Jun 2014 14:24:13 +0000

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:[email-masked]] 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.

---

From: <[email-masked]>
Date: Mon, 16 Jun 2014 14:43:03 +0000

Resending as text only, as I've been told the previous email was hard to parse.
Sorry for the spam.
-----
Hi,

Read and support.
Please find below some comments:

1)
"1. Introduction
[.]

-----------------------
2) 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 the case, this timer should probably be given a name and become a MUST to implement (it's a MAY in RFC 4271)
-----------------------  
3) 
	"  Flags for Address Family:

	                0 1 2 3 4 5 6 7
	               +-+-+-+-+-+-+-+-+
	               |F|N| Reserved  |
	               +-+-+-+-+-+-+-+-+

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].

   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."

-----------------------

This section 4.1 tries to patch section 4.2 of RFC4274 but I don't find it easy to read nor clear. 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] 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 overwrites)
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.

Thanks,
Best regards,
Bruno

Working Group,

The abstract is below. 

Sue Hares

----------

Abstract:

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 16 Jun 2014 16:38:41 -0400

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.

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".

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

---

From: <[email-masked]>
Date: Tue, 17 Jun 2014 08:02:35 +0000

Hi John, all

Thanks for the answer and clarifications.
Please see inline.

> From: John G. Scudder [mailto:[email-masked]] > Sent: Monday, June 16, 2014 10:39 PM
> 
> 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.

Thank you.

> > 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".

I agree that it's nicer and safer for pre-standard implementations.
I agree that deprecating is the way to go. Thanks for the clarification.
Mostly it reads strange to have an RFC define a code point and deprecate it the line after. Eventually an alternative to avoid "polluting" the RFC forever may be to perform an early allocation, or some chair/AD magic to make it deprecated without an RFC.
But I'm also fine with the current text. (yet may be this deprecated allocation needs to be added in the "IANA Considerations" section 6)

> > 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.

IMO, the capability flag looks useful to indicate to the peer how to trigger a full/4271 BGP session termination:
- if both BGP speaker supports gr-notification, a Hard Reset must be used
- if one speaker does not support gr-notification, a regular NOTIFICATION must be used.

So if you don't require the sender to send the N flag, you disallow the sender the ability to perform a full/4271 BGP session reset (since the receiver requires a Hard Reset message and the sender is not compliant).
( Also the sender will try to initiate a RFC 4271 restart while the receiver will initiate a 4724/gr-notification restart. Looks a priori complex to me, but I'm not sure this will work (e.g. the sender will a priori clear the "F" (Forwarding State bit), no? so the receiver will still have to remove routes from its RIB and gr-notification will not really succeed in preserving the RIB))

Regards,
Bruno

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 17 Jun 2014 10:59:33 -0400

Apropos the N flag, you're right of course. Thanks.

--John