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

[<[e-mail]>]

Hi John, all

Thanks for the answer and clarifications.
Please see inline.


> From: John G. Scudder [mailto:[e-mail]] > 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.

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

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)

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

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

_________________________________________________________________________________________________________________________

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.