Subject: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension

From: Jie Dong <[email-masked]>
Date: Tue, 09 Aug 2011 07:46:57 +0000

Dear all, 

Internet-Draft draft-dong-idr-end-of-rib-use-extension was submitted before Quebec IETF. The url is: http://tools.ietf.org/html/draft-dong-idr-end-of-rib-use-extension-00

Since BGP End-of-Rib (EoR) would be useful for general BGP convergence, this draft proposes to define a EoR capability to negotiate the use of EoR between BGP peers. This makes EoR an independent feature and could be used without supporting or enabling GR capability. As according to BGP GR (RFC4724), BGP peers can only negotiate the combination of EoR and GR capability.

We've received some offline comments, one of which suggested an alternative solution: respin GR specification and cover this scenario: negotiate only EoR, no GR. 

Thus we would have two alternatives here:
either we define a simple and dedicated capability for EoR, 
or we respin BGP GR with some further capability negotiation functionality to cover this case.

We would like to solicit feedbacks and opinions on this draft and also the alternatives.

Many thanks,
Jie

---

From: Enke Chen <[email-masked]>
Date: Tue, 09 Aug 2011 12:13:49 -0700

Hi, Jie:

IMO RFC 4724 is sufficiently clear about the use of EOR, and also 
specifies the use of the GR capability without AFI/SAFI for indicating 
the EOR support without performing GR.  Please see excerpt from RFC 4724 
below.

Granted there are some inconsistencies in RFC 4724.  A re-spin of RFC 
4724 seems in order. Actually a re-spin is already on the IDR WG status 
report presented at the IETF-81.

There is no need for a new capability, though, as there is no backward 
compatibility issue for sending and receiving the GR capability (with or 
without AFI/SAFI).

In short, I do not see a need for draft-dong-idr-end-of-rib-use-extension.

-- Enke

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

RFC 4724 (GR)

2. Marker for End-of-RIB
     .....

    Although the End-of-RIB marker is specified for the purpose of BGP
    graceful restart, it is noted that the generation of such a marker
    upon completion of the initial update would be useful for routing
    convergence in general, and thus the practice is recommended.

    In addition, it would be beneficial for routing convergence if a BGP
    speaker can indicate to its peer up-front that it will generate the
    End-of-RIB marker, regardless of its ability to preserve its
    forwarding state during BGP restart.  This can be accomplished using
    the Graceful Restart Capability described in the next section.

4.  Operation

    A BGP speaker MAY advertise the Graceful Restart Capability for an
    address family to its peer if it has the ability to preserve its
    forwarding state for the address family when BGP restarts.  In
    addition, even if the speaker does not have the ability to preserve
    its forwarding state for any address family during BGP restart, it is
    still recommended that the speaker advertise the Graceful Restart
    Capability to its peer (as mentioned before this is done by not
    including any<AFI, SAFI>  in the advertised capability).  There are
    two reasons for doing this.  The first is to indicate its intention
    of generating the End-of-RIB marker upon the completion of its
    initial routing updates, as doing this would be useful for routing
    convergence in general.  The second is to indicate its support for a
    peer which wishes to perform a graceful restart.

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

On 8/9/11 12:46 AM, Jie Dong wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 9 Aug 2011 12:25:44 -0700

Hi Jie,

> We would like to solicit feedbacks and opinions on this draft and also the alternatives.

I don't think any new capability negotiation is required. The procedures defined in the GR spec (RFC4724) sufficiently cover what you are trying to achieve here. E.g. the following paragraph:

Moreover, many implementations do this already. The -bis for RFC4760 clearly says that an UPDATE message with empty MP_UNREACH (essentially the EOR) MUST not be treated as an error.

IMO, this is an implementation detail and let's focus on fixing those that do not do today.

Thanks,
- Pradosh

---

From: Jie Dong <[email-masked]>
Date: Wed, 10 Aug 2011 01:07:06 +0000

Hi Pradosh, 

Thanks for your comments, and please see replies inline.

>    convergence in general, and thus the practice is recommended.

I note the word here is "recommended". It would be great if all implementations generate EoR in general cases (without need of GR capability), but I'm afraid now it is not the case. 
Please note EoR would help convergence only when a BGP speaker knows ALL its peers' behavior clearly (whether they will send EoR or not). One common way to know that is through capability negotiation.

> Moreover, many implementations do this already. The -bis for RFC4760
> clearly says that an UPDATE message with empty MP_UNREACH
> (essentially the EOR) MUST not be treated as an error.

Yes this could ensure that bgp speakers would not treat EoR as error, but still this could not ensure or tell a speaker whether its peers will send EoR to itself.

> IMO, this is an implementation detail and let's focus on fixing those that

We could fix some implementations, but IMO using EoR for convergence is not only about local implementation, but also some negotiation/coordination between peers. Besides, fixing all the existing implementations may take quite a long time.

Best regards,
Jie

---

From: Jie Dong <[email-masked]>
Date: Wed, 10 Aug 2011 01:30:26 +0000

Hi Enke, 

Thanks for your comments. 

I think we agree that RFC4724 cannot cover this case well (otherwise any respin would not be needed). With RFC4724, BGP speaker can signal:
a. capability as GR restarting speaker and use of EoR, or 
b. capability as GR receiving speaker and use of EoR.
Thus there is no means of negotiating only EoR.

Clearly EoR is not something tightly bound with GR, people could use EoR without GR. Thus if people want to signal only EoR and no GR, is it appropriate to signal it using GR capability?

Our basic idea is to make EoR an independent feature, which could be used in more general cases. Thus an independent capability sounds reasonable IMO.

Best regards,
Jie

> -----Original Message-----
> From: Enke Chen [mailto:[email-masked]]
> Sent: Wednesday, August 10, 2011 3:14 AM
> To: Jie Dong
> Cc: [email-masked]; Enke Chen
> Subject: Re: [Idr] Solicit feedbacks on
> draft-dong-idr-end-of-rib-use-extension
> 
> Hi, Jie:
> 
> > Internet-Draft draft-dong-idr-end-of-rib-use-extension was submitted
> before Quebec IETF. The url is:
> http://tools.ietf.org/html/draft-dong-idr-end-of-rib-use-extension-00
> >
> > Since BGP End-of-Rib (EoR) would be useful for general BGP convergence,
> this draft proposes to define a EoR capability to negotiate the use of EoR
> between BGP peers. This makes EoR an independent feature and could be
> used without supporting or enabling GR capability. As according to BGP
> GR (RFC4724), BGP peers can only negotiate the combination of EoR and
> GR capability.
> >
> > We've received some offline comments, one of which suggested an
> alternative solution: respin GR specification and cover this scenario:
> negotiate only EoR, no GR.
> >

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 9 Aug 2011 22:16:31 -0400

Jie,

When a BGP speaker advertises the GR capability without
including any <AFI,SAFI> it is saying to the peer:
I will send an EOR when my initial update is complete and
I MAY retain your routes when you restart.

When a BGP speaker advertises your extension,
it is saying to the peer:
I will send an EOR when my initial update is complete and
I WILL NOT retain your routes when you restart.

I think. Is that correct?

Can you state a use case where the difference matters?

--
Jakob Heitz.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jie Dong
> Sent: Tuesday, August 09, 2011 6:30 PM
> To: Enke Chen
> Cc: [email-masked]
> I think we agree that RFC4724 cannot cover this case well 
> (otherwise any respin would not be needed). With RFC4724, BGP 
> speaker can signal:
> Clearly EoR is not something tightly bound with GR, people 
> could use EoR without GR. Thus if people want to signal only 
> EoR and no GR, is it appropriate to signal it using GR capability?
> 
> Our basic idea is to make EoR an independent feature, which 
> could be used in more general cases. Thus an independent 
> capability sounds reasonable IMO.
> 
> Best regards,
> Jie
> 
> > > We would like to solicit feedbacks and opinions on this 
> draft and also
> > the alternatives.
> > >
> > > Many thanks,
> > > Jie

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 10 Aug 2011 08:11:31 +0200

Hi Jie,

As we have discussed already offline I also do not see a need for new 
spec to define EoR capability as a separate document.

Text clarification of re-spined RFC4724 (with possible addition of new 
flag) would be in my opinion sufficient to address any potential doubts 
one could have reg explicit helper behaviour signaling when sending GR 
capability with null set of AFI/SAFIs.

I am of the opinion that it is always much better to focus on one clear 
specification rather then define the same functionality in multiple and 
independent documents.

Best regards,
R.

>  Since BGP End-of-Rib (EoR) would be useful for general BGP
> convergence, this draft proposes to define a EoR capability to
> negotiate the use of EoR between BGP peers. This makes EoR an
> independent feature and could be used without supporting or enabling
> GR capability. As according to BGP GR (RFC4724), BGP peers can only
> negotiate the combination of EoR and GR capability.
>
> alternative solution: respin GR specification and cover this
> scenario: negotiate only EoR, no GR.
>
> Thus we would have two alternatives here: either we define a simple
> and dedicated capability for EoR, or we respin BGP GR with some
> further capability negotiation functionality to cover this case.
>
> Many thanks, Jie _______________________________________________ Idr
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jie Dong <[email-masked]>
Date: Wed, 10 Aug 2011 06:30:41 +0000

Hi Jakob, 

> I MAY retain your routes when you restart.

In general it is saying "I am able to perform procedures of GR receiving speaker when you restart".

> I WILL NOT retain your routes when you restart.

I'd like to provide some clarification. With EoR capability, it only negotiates the use of EoR, and no other information (e.g. whether or not retain route states) is exchanged by this capability.

> Can you state a use case where the difference matters?

One use case is some bgp speakers deploy NSR and do not enable GR, thus they only want EoR but do not exchange GR capability.

Generally we would assume EoR has broader use cases than GR, and should NOT be bound with GR. Similarly, in LDP, GR (RFC3478) and End-of-LIB (RFC5919) are two independent features.

Best regards,
Jie

---

From: Jie Dong <[email-masked]>
Date: Wed, 10 Aug 2011 06:44:37 +0000

Hi Robert, 

> spec to define EoR capability as a separate document.

Got your opinion on this, thanks.

> capability with null set of AFI/SAFIs.

If you choose to re-spin RFC4724, adding new flags would definitely be needed, which is more than "text clarification". And remember this would be for negotiating features "outside" GR. Not sure if this sounds reasonable. 

> specification rather then define the same functionality in multiple and

Correct if they are exactly the same functionality:) Please note that LDP End-of-LIB and LDP GR are not the same functionality and are defined in separate documents.

Best regards,
Jie

> > Many thanks, Jie
> _______________________________________________ Idr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 10 Aug 2011 09:27:58 +0200

Hi Jie,

 > Please note that LDP End-of-LIB and LDP GR are not the same
 > functionality and are defined in separate documents.

Allow me to make an observation that LDP GR is timer driven without any 
LDP EOR marker involved in the restart procedures as described in 
rfc3478. Most likely authors of rfc3478 assumed that the amount of 
binding information as exchanged by LDP allows for such approach.

However as we all know BGP GR does define EOR as number of BGP routes to 
be exchanged during the restart of the session is >> then number of LDP 
bindings therefor IMHO comparison of LDP GR/EOR to BGP GR/EOR is not 
really apple to apple case.

Best regards,
R.

---

From: Enke Chen <[email-masked]>
Date: Wed, 10 Aug 2011 16:20:36 -0700

Hi, Jie:

There is no dispute about using EOR without performing the GR procedures 
(i.e., retaining stale routes).  That had always been the intention 
during the GR design.  The semantics of the GR capability without any 
AFI/SAFI was designed specifically for that purpose.

Unfortunately there are some inconsistencies in this area between Sect 3 
and 4 of RFC 4724.  The first two paragraphs in Section 4 talks about 
the general rules of advertising the GR cap and sending EOR.   But the 
reference in Section 3 jumps directly to Section 4.2.  The inconsistency 
needs to be fixed in a re-spin.

It a local decision whether a speaker retains stale routes from a remote 
speaker, and the decision has no impact on how the remote speaker would 
behave.  Thus no backward compatibility issue would arise from the local 
decision. That is something that should be clarified in a re-spin.

Regards,   -- Enke

-----------------------------------------
3.  Graceful Restart Capability

     ...

    When a sender of this capability does not include any<AFI, SAFI>  in
    the capability, it means that the sender is not capable of preserving
    its forwarding state during BGP restart, but supports procedures for
    the Receiving Speaker (as defined in Section 4.2 of this document).
    In that case, the value of the "Restart Time" field advertised by the
    sender is irrelevant.

---

4. Operation

    The End-of-RIB marker MUST be sent by a BGP speaker to its peer once
    it completes the initial routing update (including the case when
    there is no update to send) for an address family after the BGP
    session is established.

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

---

From: Jie Dong <[email-masked]>
Date: Thu, 11 Aug 2011 09:18:37 +0000

Hi Robert, 

> binding information as exchanged by LDP allows for such approach.

RFC5919 specifies usage guidelines of LDP End-of-LIB for LDP GR: 

  "Receiving End-of-LIB Notification from a peer in an LDP Graceful
   Restart scenario enables an LDP speaker to stop using stale
   forwarding information learned from that peer and to recover the
   resources it requires without having to wait until the time period
   expiry.  The time period expiry can still be used if the End-of-LIB
   Notification message is not received. "

> really apple to apple case.

Yes the amount of information to be exchanged may be different, but for LDP it would also be beneficial to reduce the time in GR mode and exit GR ASAP.

Regards,
Jie

> > If you choose to re-spin RFC4724, adding new flags would definitely be
> needed, which is more than "text clarification". And remember this would
> be for negotiating features "outside" GR. Not sure if this sounds
> reasonable.
> >
> > Correct if they are exactly the same functionality:) Please note that LDP
> End-of-LIB and LDP GR are not the same functionality and are defined in
> separate documents.
> >
> > Best regards,
> > Jie
> >
> >>
> >>> Dear all,
> >>>

---

From: Jie Dong <[email-masked]>
Date: Thu, 11 Aug 2011 11:16:03 +0000

Hi Enke,

Thanks for your replies.

> AFI/SAFI was designed specifically for that purpose.

It's good that we agree on this scenario. IMO now GR capability with null AFI/SAFI is for signaling "GR helper and EoR". If we want to use it to signal EoR only, we may need another way to signal the GR helper capability.

> needs to be fixed in a re-spin.

IMO the two scenarios mentioned in sec 4 cannot be signaled separately through one single capability format. Thus some additional flag needs be defined if you choose to re-spin GR RFC, and such extension would be for scenarios NOT enabling GR. That's why the draft proposes a dedicate capability for EoR only scenario.

> decision. That is something that should be clarified in a re-spin.

IMO whether a speaker would retain stale routes SHOULD be signaled to its peer, then the peer (and peer's operator) could know whether GR is deployed and would take effect between the two BGP speakers. Otherwise the operator cannot tell where in the network GR is deployed and where only EoR is used.

Best regards,
Jie

> > I think we agree that RFC4724 cannot cover this case well (otherwise any
> respin would not be needed). With RFC4724, BGP speaker can signal:
> > Clearly EoR is not something tightly bound with GR, people could use
> EoR without GR. Thus if people want to signal only EoR and no GR, is it
> appropriate to signal it using GR capability?
> >
> > Our basic idea is to make EoR an independent feature, which could be
> used in more general cases. Thus an independent capability sounds
> reasonable IMO.
> >
> > Best regards,
> > Jie
> >
> convergence,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 11 Aug 2011 15:15:56 +0200

Hi Jie,

> It's good that we agree on this scenario. IMO now GR capability with
> null AFI/SAFI is for signaling "GR helper and EoR".

I would not agree with that. It is in fact just the opposite.

> If we want to use it to signal EoR only, we may need another way to
 > signal the GR helper capability.

+

> IMO the two scenarios mentioned in sec 4 cannot be signaled
> separately through one single capability format. Thus some additional
> flag needs be defined

While I did suggested the addition of flag after rethinking this a bit 
more I do not think it is necessary.

Here is my idea:

--

* When you signal GR capability with null AFI/SAFI list - it just means 
use of EOR - it does not mean you support helper mode.

* When you signal GR capability with non-null AFI/SAFI (at least one 
AFI/SAFI included) - it will mean use of EOR, helper mode support + GR 
support for this/those AFI/SAFIs.

--

If the GR RFC will clarify that to reflect such semantics I think all 
confusions are addressed and all cases covered without any need for 
protocol extension.

Thoughts ?

Thx,
R.

---

From: Cayle Spandon <[email-masked]>
Date: Tue, 16 Aug 2011 07:32:07 -0400

I think it is fair to say that everyone agrees that EoR makes sense
without GR.

With 20/20 hindsight, it would probably have been "cleaner" to define
a separate capability for EoR and GR.

But we have to play the cards we have been dealt, and at this point I
can sympathize with the position that clarifying/tweaking the existing
specs would minimize churn and confusion.

(That said, I would not object to "doing the right thing from an
architecture point of view" and creating a new EoR capability even
though doing so would create a new set of confusions on how the new
EoR capability would interact with the existing GR capability.)

Regardless of what we decide to do (tweak GR capability or add EoR
capability) I think that the following 3 problems need to fixed:

1. There must be a way of negotiating EoR in such a way that the
receiver can be 100% certain that it will receive an EoR at the end of
initial convergence. As pointed out by earlier posters, there are some
inconsistencies in the current GR spec which cause it to be unclear
(for certain scenarios, notably when <AFI,SAFI> is included) whether
an EOR should be sent after initial convergence.

2. It is not sufficient to simply clarify the language in a respin of
the GR spec without any protocol changes. If we did that, the receiver
of a GR capability would have no way to know 100% sure that the remote
side intends to send an EoR after initial convergence (because it
doesn't know whether the remote side was implemented before or after
the "clarifications"). Thus, we need to add "something" (either a new
flag in the existing GR capability to a new EoR capability) which
conveys to the other side: "I guarantee that I will send EoR after
initial convergence".

3. We also need to clarify the behavior for router-refresh. In my
opinion it would be good to also indicate end-of-route-refresh with an
EoR (or similar) message.

-- Bruno

PS to muddle the waters some more: If we do end up going down the path
of a new EoR capability, then I would suggest that the authors of
draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could
be enhanced to include SoR (Start-of-RIB) as well which would cover
the need for start-of-route-refresh and end-of-route-refresh.

On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk <[email-masked]> wrote:
> While I did suggested the addition of flag after rethinking this a bit more
> I do not think it is necessary.
>
> Here is my idea:
>
> --
>
> * When you signal GR capability with null AFI/SAFI list - it just means use
> of EOR - it does not mean you support helper mode.
>
> confusions are addressed and all cases covered without any need for protocol
> extension.
>
> Thoughts ?
>
> Thx,
> R.
>
>

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 16 Aug 2011 10:23:47 -0400

Again:

--
Jakob Heitz.

On Aug 16, 2011, at 4:32 AM, "Cayle Spandon" <[email-masked]<mailto:[email-masked]>> wrote:

-- Bruno

On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jie,

+

Here is my idea:

--

--

Thoughts ?

Thx,
R.

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Jie Dong <[email-masked]>
Date: Wed, 17 Aug 2011 03:13:56 +0000

Hi Jakob, 

One could use BGP GR for graceful session reset. 

1) If the speaker which performs GR session reset knows its peer would perform GR receiving speaker procedure, it would keep forwarding states with stale routes when the session is reset and update the forwarding state when GR is finished.

2) If the speaker which performs session reset knows its peer would not perform GR helper procedure, when the session resets it would immediately withdraw all the routes received from that peer and update forwarding states.

So if the speaker which performs session reset does not know whether its peer supports GR helper mode or not , it would first keep stale routes in forwarding table for a while, then it would fail to finish GR and withdraw that peer's routes and update the forwarding table with routes from other peers. This could consume more resources and may impact the data traffic.

Besides, if operator knows whether one BGP peer support GR helper or not, it may choose different mechanisms for maintenance.

Best regards,
Jie

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Heitz
> Sent: Tuesday, August 16, 2011 10:24 PM
> To: Cayle Spandon
> Cc: [email-masked]
> On Aug 16, 2011, at 4:32 AM, "Cayle Spandon"
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Jie,
> 
> protocol

---

From: Cayle Spandon <[email-masked]>
Date: Thu, 18 Aug 2011 07:43:48 -0400

Jakob Heitz> When a BGP speaker advertises the GR capability without
Jakob Heitz> including any <AFI,SAFI> it is saying to the peer:
Jakob Heitz> I will send an EOR when my initial update is complete and
Jakob Heitz> I MAY retain your routes when you restart.

Jakob Heitz> When a BGP speaker advertises your extension,
Jakob Heitz> it is saying to the peer:
Jakob Heitz> I will send an EOR when my initial update is complete and
Jakob Heitz> I WILL NOT retain your routes when you restart.

One nitpick (not relevant to the discussion at hand): if we have a new
separate EoR capability, sending it would not make any statement about
whether or not router are retained after a restart. That would be an
orthogonal issue handled by the GR capability.

Jakob Heitz> Can you state a use case where the difference matters?

I see your point, which is (I think) that we can use the existing GR
capability without an <AFI,SAFI> to advertise "I will (a MUST) send an
EoR after initial convergence".

I believe there is a problem with this approach.

Let's say that a BGP speaker wants to announce the following:

(a) I am able to preserve forwarding state for <AFI,SAFI> during a
restart. This requires sending a GR capability with <AFI,SAFI>.

(b) I will (a MUST) send an EoR after initial convergence. This
requires sending a GR capability without an <AFI,SAFI>.

Since a single GR capability cannot have and not have an <AFI,SAFI> at
the same time, this would require sending two separate GR capabilities
in a single OPEN message (one GR cap with one or more <AFI,SAFI> and
one GR cap without).

This is explicitly forbidden in the 2nd to last paragraph of section 3
of RFC 4724.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Aug 2011 16:44:03 +0200

Hi,

> requires sending a GR capability without an <AFI,SAFI>.

Sending GR capability with <AFI,SAFI> also means that EOR is mandatory 
(a MUST). So I do not think I see a problem in your particular example.

Best regards,
R.

> Jakob Heitz>  including any<AFI,SAFI>  it is saying to the peer:
> capability without an<AFI,SAFI>  to advertise "I will (a MUST) send an
> (a) I am able to preserve forwarding state for<AFI,SAFI>  during a
> restart. This requires sending a GR capability with<AFI,SAFI>.
>
> requires sending a GR capability without an<AFI,SAFI>.
>
> Since a single GR capability cannot have and not have an<AFI,SAFI>  at
> in a single OPEN message (one GR cap with one or more<AFI,SAFI>  and
> one GR cap without).
>
> On Tue, Aug 16, 2011 at 10:23 AM, Jakob Heitz<[email-masked]>  wrote:
>> Again:
>>
>> including any<AFI,SAFI>  it is saying to the peer:
>> On Aug 16, 2011, at 4:32 AM, "Cayle Spandon"<[email-masked]<mailto:[email-masked]>>  wrote:
>>
>> (for certain scenarios, notably when<AFI,SAFI>  is included) whether
>> On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk<[email-masked]<mailto:[email-masked]>>  wrote:
>> Hi Jie,
>>

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 18 Aug 2011 13:41:04 -0400

I think I can see a use case.
A BGP speaker wants to tell its neighbors:

If the BGP session to me goes down, you MUST immediately
remove the routes that I advertised to you,
AND
when I have completed my initial update to you,
I will send you an EOR.

--
Jakob Heitz.

> From: Cayle Spandon [mailto:[email-masked]] 
> Sent: Thursday, August 18, 2011 4:44 AM
> To: Jakob Heitz
> Cc: [email-masked]

---

From: Jie Dong <[email-masked]>
Date: Fri, 19 Aug 2011 08:51:15 +0000

Hi Jakob, 

That's also what I wanted to describe in my previous mail, thanks for your summarization. 

This is the case to let peers know this speaker "would only send EOR for initial route update and would not behave as GR helper".

Best regards,
Jie

> Sent: Friday, August 19, 2011 1:41 AM
> To: Cayle Spandon
> Cc: [email-masked]