Subject: RE: "BGP graceful restart" clarifications

From: "Khanna, Vinay" <[email-masked]>
Date: Fri, 19 Jul 2002 02:16:23 -0400

John,

Thanks for your clarifications. Please find my responses inlined with
[Vinay].

Regards.
Vinay:)

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 5:20 PM
To: Khanna, Vinay
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; 'Alex Zinin'; Khanna, Vinay
Subject: Re: "BGP graceful restart" clarifications

At 2:15 AM -0400 7/18/02, Khanna, Vinay wrote:
>Hello Everybody,
>
>I've some doubts with respect to the graceful restart mechanisms for BGP.
>
>1) Section 6.1 says
>"When the Restarting Speaker restarts, if possible it shall retain the
>forwarding state for the BGP routes in the Loc-RIB, and shall mark them as
>stale."
>This sentence gives an impression as if the Loc-RIB is retained in certain
>cases. Why is it so? Isn't it enough if ONLY forwarding state is preserved
>on the restarting speaker? Although the stale route marking mechanism is
>necessary on the receiving side (to avoid flapping), I dont feel it's
>necessity on the restarting side. It 's enough if the route-selection
>procedure is deferred on the restarting speaker to avoid unnecessary route
>advertisements as and when routes are received from receiving speakers. Am
I
>missing something? Please clarify.

As with any routing protocol spec, the spec describes behavior.  The 
implementation is up to you.  Is it possible to produce the described 
implementation using retained FIB information only?  I would say yes.
[Vinay]: That answers my concern.

(Many implementations don't physically implement distince Loc-RIB, 
Adj-RIB-In, etc, but they're still used for description in the base 
spec.)
[Vinay]: Section 3.2, draft-17 explicitely states
   "Although the conceptual model distinguishes between Adj-RIBs-In, Loc-
   RIB, and Adj-RIBs-Out, this neither implies nor requires that an
   implementation must maintain three separate copies of the routing
   information. The choice of implementation (for example, 3 copies of
   the information vs 1 copy with pointers) is not constrained by the
   protocol."

Shouldn't a similar statement be added in the GR draft?

>2) Does this draft address only planned BGP outages?

It may apply to any outage.
[Vinay]: Agreed. But in unplanned outages, ONLY the restart mechanism for
the Restarting Speaker is applicable. The Receiving Speaker shall NOT retain
the routes received from the Restarting Speaker on detecting a connection
closure; since the Forwarding State bit is 0. Thoughts?

>Can these mechanisms be
>applied to a subset of peers too?

Sure, although one might want to be judicious about exactly how one 
did such a mixed deployment.

>3) What happens when both the speakers advertise themselves as 'receiving
>speakers' (by setting the BGP Restart State bit to FALSE)? Should usual BGP
>procedures as specified in draft-17 be followed in this scenario?

They should both follow the procedures for "receiving speaker".
[Vinay]: On revisiting the draft, it makes sense. The Receiving Speaker
shall either flush the peer routes (draft-17 behaviour) OR shall mark them
as stale routes (graceful restart behaviour) depending on the value of the
Forwarding State bit. Thoughts?

>Thanks in advance,
>Vinay:)

Regards,

--John

---

From: "Stephen Waters" <[email-masked]>
Date: Fri, 19 Jul 2002 10:07:38 +0100

> closure; since the Forwarding State bit is 0. Thoughts?

The receiving speaker should take any failure of the peer of a 
signal to enter GR processing if the peer sent the GR option.
The restarting router then has 'restart-time' to reconnect to the 
receiving speaker before the stale routes on the the receiving speaker
are deleted.

Forwarding from the receiving speaker continues. 

Note :

"It is noted that the normal BGP procedures must be followed when the
   TCP session terminates due to the sending or receiving of a BGP
   NOTIFICATION message."

So, the 'end' of the restarting peer was messy to some degree. Whether
the cpu was planned to bounce or not should not make any difference to 
the outcome -ideally.  

Regards, Steve.

---

From: "Khanna, Vinay" <[email-masked]>
Date: Fri, 19 Jul 2002 05:50:42 -0400

Steve,

Thanks for the comments. Please find my responses inlined with [Vinay].

Regards.
Vinay:)

-----Original Message-----
From: Stephen Waters [mailto:[email-masked]]
Sent: Friday, July 19, 2002 2:38 PM
To: Khanna, Vinay
Cc: [email-masked]
Subject: RE: "BGP graceful restart" clarifications

[Vinay] Agreed.

Note :

[Vinay] True.

So, the 'end' of the restarting peer was messy to some degree. Whether
the cpu was planned to bounce or not should not make any difference to 
the outcome -ideally.  
[Vinay]: I dont agree here. The Receiving Speaker behaviour is different in
these scenarios. During unplanned outages, the Restarting Speaker sets the
Forwarding State bit to 0. This forces the Receiving Speaker to delete the
stale routes after the session re-establishment. This will happen even if
the session is re-established within 'Restart Time'.
From Section 6.2
   "Once the session is re-established, if the "Forwarding State" bit for
   a specific address family is not set in the newly received Graceful
   Restart Capability, or if a specific address family is not included
   in the newly received Graceful Restart Capability, or if the Graceful
   Restart Capability isn't received in the re-established session at
   all, then Receiving Speaker shall immediately remove all the stale
   routes from the peer that it is retaining for that address family."

Regards, Steve.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 19 Jul 2002 08:11:23 -0400

>closure; since the Forwarding State bit is 0. Thoughts?

No, the FS bit can be set, it depends on the restarting speaker.  The 
receiving speaker just takes action as given in the spec according to 
the FS bit, no additional cleverness is required. :-)

>Forwarding State bit. Thoughts?

Right.

--John

---

From: "Khanna, Vinay" <[email-masked]>
Date: Fri, 19 Jul 2002 09:35:03 -0400

No, the FS bit can be set, it depends on the restarting speaker.  The 
receiving speaker just takes action as given in the spec according to 
the FS bit, no additional cleverness is required. :-)
[Vinay]: Got it. Last para in section 6.1 misled me to believe so:)

Right.

--John