Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 22 Jan 2014 17:19:49 +0000

I support the publication of this ID as an RFC.
I have one comment:

Quoting from Section 4:
"When a route entry in the "ADJ-RIB-Out" changes, only
   the modified route entry needs to be advertised."

I think the above statement is true in general, regardless of the route refresh.
Just wondering if it should be clearer in the document what the operational
implication is in the context of enhanced route refresh.
If changes happen during the ERR (between BoRR and EoRR),
do you advertise each change right away, or do you finish sending
the Adj-RIB-Out (whatever you had at the start of route refresh)
and then advertise the changes (just prior to sending the EoRR)?

Sriram

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 22 Jan 2014 20:49:10 +0000

My interpretation:

It means the implementation does not have to do a snapshot.
If a route changes during the refresh (after BoRR, before EoRR),
it is an implementation decision whether to advertise just the latest version of the route
or also the older version.

Suppose a speaker sends BoRR, then sends an update for a particular route,
then that route changes, then the speaker sends updates for other routes,
then it sends EoRR. The final change to the particular route may be sent
before or after the EoRR.

In another scenario, a speaker sends BoRR and starts advertising routes.
Then a particular route that has not yet been advertised as part of the refresh changes.
It is an implementation decision whether to just advertise the latest version
of the route or the original version. The latest version must be advertised either
before or after the EoRR. At least one version of the route must be advertised
before the EoRR.

What it means is that an implementation is free to consider an incoming
route change to have happened before, during or after the refresh operation.

The intent in the draft is to allow the receiver to delete stale routes
upon receipt of the EoRR.

Thanks,
Jakob.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Sriram, Kotikalapudi
Sent: Wednesday, January 22, 2014 9:20 AM
To: [email-masked]; "Keyur Patel (keyupate)"
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Quoting from Section 4:

I think the above statement is true in general, regardless of the route refresh.
Just wondering if it should be clearer in the document what the operational implication is in the context of enhanced route refresh.
If changes happen during the ERR (between BoRR and EoRR), do you advertise each change right away, or do you finish sending the Adj-RIB-Out (whatever you had at the start of route refresh) and then advertise the changes (just prior to sending the EoRR)?

Sriram

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

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 23 Jan 2014 00:19:00 +0000

+1.

Regards,
Keyur

On 1/22/14 12:49 PM, "Jakob Heitz" <[email-masked]> wrote:

>Just wondering if it should be clearer in the document what the
>operational implication is in the context of enhanced route refresh.
>If changes happen during the ERR (between BoRR and EoRR), do you
>advertise each change right away, or do you finish sending the
>Adj-RIB-Out (whatever you had at the start of route refresh) and then
>advertise the changes (just prior to sending the EoRR)?
>
>Sriram
>   
> 
>
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 23 Jan 2014 16:11:02 +0000

Thanks, Jakob. Your interpretation is helpful and Kuyur agrees. So that's good.

>The intent in the draft is to allow the receiver to delete stale routes upon receipt
>of the EoRR.

Yes, and it seems the intent is even more flexible than that.
>From Section 4:
  "An implementation MAY impose a locally configurable upper bound on
   how long it would retain any stale routes.  Once the upper bound is
   reached, the implementation MAY remove any routes from the peer that
   are still marked as stale for that <AFI, SAFI> without waiting for an
   EoRR message."

Just to clarify (for the chairs): I support the draft advancing to RFC.

Sriram

>From: Jakob Heitz [mailto:[email-masked]]
>Sent: Wednesday, January 22, 2014 3:49 PM
>To: Sriram, Kotikalapudi; [email-masked]; "Keyur Patel (keyupate)"
>Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh
>
>My interpretation:
>
>If a route changes during the refresh (after BoRR, before EoRR), it is an
>implementation decision whether to advertise just the latest version of the
>route or also the older version.
>
>then that route changes, then the speaker sends updates for other routes, then
>it sends EoRR. The final change to the particular route may be sent before or
>after the EoRR.
>
>It is an implementation decision whether to just advertise the latest version of
>the route or the original version. The latest version must be advertised either
>What it means is that an implementation is free to consider an incoming route
>change to have happened before, during or after the refresh operation.
>
>The intent in the draft is to allow the receiver to delete stale routes upon receipt
>of the EoRR.
>
>Thanks,
>Jakob.
>

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 23 Jan 2014 16:53:59 +0000

Other cases:
A speaker should never send an EoRR without first having sent a BoRR.
A speaker can not "nest" refreshes. I.e. it should not send two BoRR without an intervening EoRR or send two EoRR without an intervening BoRR. Note that the behavior of a receiving speaker in the face of such attempted nesting "just works" with the rules stated in the draft.
A refresh cannot last through a graceful restart. I.e. a speaker can not send BoRR, then reset the session, start a new session with graceful restart, then send an EoRR. A session reset must cancel any stale markings due to a previous BoRR. Of course, if graceful restart is in effect, then everything gets stale marked again.
A speaker must not send BoRR before having sent EoR (to complete a GR).

If a speaker receives a BoRR, before having received an EoR on a session with GR enabled, it should ignore the BoRR and log an error. At least, that's what I would do. I really don't think it's worth inventing two separate stale marks, one for GR and one for ERR, just to handle this case. Other opinions?

--
Jakob Heitz.

> On Jan 23, 2014, at 8:11 AM, "Sriram, Kotikalapudi" <[email-masked]> wrote:
>

---

From: "Chris Hall" <[email-masked]>
Date: Thu, 23 Jan 2014 17:35:14 -0000

Jakob Heitz wrote (on Thu 23-Jan-2014 at 16:54 +0000):
...
> If a speaker receives a BoRR, before having received an EoR on a
> session with GR enabled, it should ignore the BoRR and log an
> error. At least, that's what I would do. I really don't think it's
> worth inventing two separate stale marks, one for GR and one for
> ERR, just to handle this case. Other opinions?

Does EoRR mean something actually different to EoR ?

>From the receiver's perspective both mean that any (remaining) stale
routes must now be banged on the head.  After a restart, EoR may be
the trigger for other work which has been deferred to this point, but
the receiver can work that much out for itself.

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 23 Jan 2014 18:37:57 +0000

Oh, another case:
A route refresh request is received before the EoR is sent.
I'll retract my statement to ignore BoRR before EoR is received.

Thanks,
Jakob.

-----Original Message-----
From: Chris Hall [mailto:[email-masked]] 
Sent: Thursday, January 23, 2014 9:35 AM
To: [email-masked]
Cc: Jakob Heitz
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

> session with GR enabled, it should ignore the BoRR and log an error. 
> At least, that's what I would do. I really don't think it's worth 
> inventing two separate stale marks, one for GR and one for ERR, just 
> to handle this case. Other opinions?

>From the receiver's perspective both mean that any (remaining) stale routes must now be banged on the head.  After a restart, EoR may be the trigger for other work which has been deferred to this point, but the receiver can work that much out for itself.

Chris

---

From: "Chris Hall" <[email-masked]>
Date: Thu, 23 Jan 2014 20:17:42 -0000

Jakob Heitz wrote (on Thu 23-Jan-2014 at 18:38 +0000):
...
> I'll retract my statement to ignore BoRR before EoR is received.

So... there are two operations:

 (1) mark everything received "stale", and set stale-timer.

 (2) flush anything which is still "stale", and stop stale-timer.

 (3) wait for BoRR, process UPDATEs but ignore EoR.

Receiving BoRR => (1).

Restarting gracefully => (1).

EoR => (2) (and perhaps some other stuff).

Timing out => (2).

Sending route-refresh request (RRQ) => (3) -- so that:

  a) if is restarting gracefully (so EoR not yet received
     or processed) then is not confused by an EoR rolling
     up -- the BoRR signals start of response RRQ.

     On receipt of an RRQ, the receiver sends BoRR and
     starts sending from the beginning.

  b) similarly if is in the middle of a route-refresh (RR)
     started by an earlier RRQ or one initiated by the
     other end sending a BoRR.

  c) if an RRQ crosses with a BoRR initiated at the other 
     end, the sender of the BoRR has to go back to the
     beginning, and send another BoRR.

     The sender of the RRQ interprets the two incoming BoRRs
     as (1) response to RRQ, and then (2) RR initiated by
     far end.

     The sender of the BoRR thinks the two outgoing BoRRs
     are (1) initiate RR, and then (2) respond to RRQ.

     Some effort has been wasted, tant pis.

Or is there something I'm missing ?

If an RRQ is sent, but no BoRR rolls up in a timely fashion... does
the sender of the RRQ treat everything as stale and flush the lot, or
does it proceed with what it has... does it send another RRQ, what ?
Clearly it whimpers, logging-wise or other-wise.

[One thing: suppose the sending side of the RR has a number of pending
UPDATEs when it receives the RRQ.  I suppose it makes sense to send
those first, before sending the rest -- given that the pending UPDATEs
represent actual changes, while the rest is generally going to simply
freshen the ones marked stale ?  Any UPDATEs that arrive after sending
RRQ, but before receiving BoRR, can be processed into the RIB, and
marked stale when the BoRR does arrive.  I guess the sending side of
the RR could hold off sending the BoRR until it has emptied any
pending UPDATEs queue.]

Chris

> error.
> From the receiver's perspective both mean that any (remaining)
> stale routes must now be banged on the head.  After a restart, EoR
> may be the trigger for other work which has been deferred to this
> point, but the receiver can work that much out for itself.
> 
> Chris

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 23 Jan 2014 20:39:07 +0000

No (3) needed.
Then there is no message crossing problem.
Either EoR or EoRR deletes the stales.
The sender of the routes needs to ensure that it sends all routes again after sending BoRR before sending either Eor or EoRR.

Thanks,
Jakob.

-----Original Message-----
From: Chris Hall [mailto:[email-masked]] 
Sent: Thursday, January 23, 2014 12:18 PM
To: [email-masked]
Cc: Jakob Heitz
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Receiving BoRR => (1).

Timing out => (2).

If an RRQ is sent, but no BoRR rolls up in a timely fashion... does the sender of the RRQ treat everything as stale and flush the lot, or does it proceed with what it has... does it send another RRQ, what ?
Clearly it whimpers, logging-wise or other-wise.

[One thing: suppose the sending side of the RR has a number of pending UPDATEs when it receives the RRQ.  I suppose it makes sense to send those first, before sending the rest -- given that the pending UPDATEs represent actual changes, while the rest is generally going to simply freshen the ones marked stale ?  Any UPDATEs that arrive after sending RRQ, but before receiving BoRR, can be processed into the RIB, and marked stale when the BoRR does arrive.  I guess the sending side of the RR could hold off sending the BoRR until it has emptied any pending UPDATEs queue.]

Chris

---

From: Chris Hall <[email-masked]>
Date: Thu, 23 Jan 2014 22:29:57 +0000

> No (3) needed.

OK... having negotiated enhanced-rr, sending RRQ has no effect on staleness of routes, or much of anything else.  Now only incoming BoRR and a graceful restart set stale.  EoR flushes stale.

[This is a change of behaviour for RRQ... which is OK.  The receiver of the RRQ has promised to support enhanced-rr, so can be depended on to send BoRR in due course.]

I guess BoRR need not flush existing stale, but in that case it should not stop an existing stale-timer.  (This is similar to not flushing stale if gracefully restarts in the middle of a graceful restart -- or an enhanced-rr, for that matter.)  The sender of the BoRR could send an EoR first if it wanted to force the issue, though in turn the receiver could ignore EoR before BoRR if it has sent an RRQ.

> Then there is no message crossing problem.

OK... given that RRQ has no effect on state, it doesn't matter if the far end is psychic, and sends BoRR before it sees the RRQ :-)

> The sender of the routes needs to ensure that it sends all routes again after sending BoRR before sending either Eor or EoRR.

I remain puzzled as to the need for EoRR.

Chris

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 23 Jan 2014 23:53:48 +0000

[Trimming the remaining message & hoping that I am not answering out of
context] :)

Hi Chris,

>I remain puzzled as to the need for EoRR.

As per RFC4724, EOR is signaled to indicate exchange of initial Routing
table updates.
Amongst other things (as you indicated), implementations are required to
defer route selection process till EOR is received.

EORR on other hand indicates exchange of subsequent Routing table updates.

Both of them are enabled using different capabilities.

We believe they have different semantics and wanted to avoid overloading
EOR.

Best Regards,
Keyur

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 24 Jan 2014 00:07:14 +0000

Don't worry. Just send another BoRR.
The rules in the draft work.
The sender rewinds to send all again, the receiver marks all stale again.

Thanks,
Jakob.

---

From: "Chris Hall" <[email-masked]>
Date: Fri, 24 Jan 2014 20:00:27 -0000

Keyur Patel wrote (on Thu 23-Jan-2014 at 23:54 +0000):
...

> As per RFC4724, EOR is signaled to indicate exchange of initial
> Routing table updates.
>
> Amongst other things (as you indicated), implementations are
> required to defer route selection process till EOR is received.
> 
> We believe they have different semantics and wanted to avoid
> overloading EOR.

So, the "initial update" (per RFC4724), graceful or otherwise, is
intended to be orthogonal to route-refresh triggered by either
route-refresh request (RRQ) or BoRR.

Hence, any route-refresh during the "initial update" (however bonkers)
would be treated as being nested inside that initial update -- so
start and end before the EoR.

The straightforward approach to BoRR during "initial update" is for
the sender (of the BoRR) to rewind and then keep going until it has
sent everything there is to send.  The EoRR and EoR are then triggered
simultaneously but sent in that order.  The receiver of the BoRR
(re-)marks everything stale (not flushing existing stale and not
restarting any stale-timer, presumably) and proceeds until it sees
EoRR and then EoR (and, possibly, further BoRR before the EoRR).  This
approach implicitly uses the same stale marking and flushing, and the
same stale-timer as (any) Graceful Restart -- making the EoRR,
largely, redundant in this state.

One could argue that, during initial update, after a BoRR the sender
could/should only repeat the routes which have been sent up to that
point, and then issue the EoRR.  The initial update would then proceed
from where it left off.  This is fully consistent with treating
"initial update" and route-refresh as orthogonal, but complicates
things, to no obvious advantage.  If such a "clever" approach were
deemed to be a useful implementation option, the specification needs
to provide for the combinations of "clever" and "straightforward"
senders and receivers.

It seems to me that initial update interacts with enhanced
route-refresh, so they aren't entirely orthogonal, and the interaction
could do with being defined.

Yet another option would be to ban BoRR in initial update state, or
define it to implicitly terminate that state (BoRR => EoR) (it's not
clear to me how useful BoRR is in initial update state).  And,
Enhanced Route-Refresh could be suppressed in initial update state, so
that RRQ operates as now (for what that's worth).  These steps
eliminate the whole BoRR/EoRR during initial update kerfuffle
altogether.

Finally, perhaps the conclusion is that during initial update, BoRR
really means "I am restarting the initial update"... and perhaps BoRR
should not be overloaded here ?

Chris

PS: I hear what you say, but I cannot help feeling that EoR could be
enabled for its current semantics (when in "initial update" state) by
the Graceful Restart capability, and enabled for EoRR semantics (when
not in "initial update" state) by the Enhanced Route-Refresh
capability.  There would then be one less message type to worry about
:-)  And the meaning of the combined EoR/EoRR message is explicitly
dependent on the "initial update" state.

---

From: Enke Chen <[email-masked]>
Date: Fri, 24 Jan 2014 12:11:36 -0800

No overloading of the existing semantics of EOR, please.  There have 
been many lessons from even minimal and  innocent deviation of semantics 
(e.g., using empty UPDATE as EOR).

-- Enke

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 24 Jan 2014 20:19:23 +0000

Chris,

I think the draft, as written, works.
It's a bit hard to verify all the cases and as you can see from the email chain, I did stumble at one point,
but I can see that it all works now.

Can you see something that doesn't work?

PS. your suggestion of NOT rewinding when sending BoRR before EoR does NOT work.

Thanks,
Jakob.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Enke Chen
Sent: Friday, January 24, 2014 12:12 PM
To: Chris Hall; [email-masked]
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

No overloading of the existing semantics of EOR, please.  There have been many lessons from even minimal and  innocent deviation of semantics (e.g., using empty UPDATE as EOR).

-- Enke

On 1/24/14 12:00 PM, Chris Hall wrote:
>> Amongst other things (as you indicated), implementations are required 
>> to defer route selection process till EOR is received.
>>

---

From: "Chris Hall" <[email-masked]>
Date: Fri, 24 Jan 2014 20:22:42 -0000

Jakob Heitz wrote (on Fri 24-Jan-2014 at 00:07 +0000):
...
> The sender rewinds to send all again, the receiver marks all stale

Graceful Restart is, of course, a separate topic -- but the Receiving
Speaker action is similar to the response to BoRR, and begs
comparison.  What's more, GR and Enhanced Route-Refresh interact.  In
GR, the process of marking routes stale (currently) requires any
existing stale to be immediately flushed.  The draft is silent on
whether BoRR flushes old stale or restarts any existing stale-timer,
whether set by GR or BoRR or otherwise -- perhaps these are intended
to be implementation decisions ?

I observe that, by rule, EoRR is sent when all routes have been sent.
Hence, EoRR is a terminator (BoRR and EoRR are not brackets).  And the
effect of BoRR is context independent.

So, as you say, the rules cope with:

  A) send: RRQ
     recv:         BoRR u1 u2  BoRR u1 u2 u3 ... EoRR

  B) recv:            RRQ
     send: BoRR u1 u2     BoRR u1 u2 u3 ... EoRR

[where time runs left to right, and this is intended to show the
conversation from the perspective of the two parties 'A' and 'B'.]

The receiver of the BoRR ('A') can (apparently) decide whether to
flush stale and/or restart its stale-timer on receipt of the second
BoRR -- for my money: I would not flush stale and I would not restart
the stale-timer.

In the case shown, rewinding and starting again with the second BoRR
is a sad waste of effort.  But the case is indistinguishable from:

  A) send:           RRQ
     recv:   BoRR u1     u2 BoRR u1 u2 u3 ... EoRR
 
  B) recv:            RRQ
     send: BoRR u1 u2     BoRR u1 u2 u3 ... EoRR

as far as 'B' is concerned.  But these are extreme-fringe cases... so
tant pis.

FWIW, other bonkers cases which "just work" include:

  A) send: RRQ
     recv:     BoRR u1 u2 EoRR   BoRR u1 u2 EoRR

  B) recv:                 RRQ
     send: BoRR u1 u2 EoRR     BoRR u1 u2 EoRR

and:

  A) send:          RRQ
     recv:   BoRR u1   u2 EoRR  BoRR u1 u2 EoRR

  B) recv:                 RRQ
     send: BoRR u1 u2 EoRR     BoRR u1 u2 EoRR

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 24 Jan 2014 20:37:13 +0000

Silence means don't do it.
You would definitely NOT want BoRR to flush old stales.
Restarting the timer might be a good idea.

Thanks,
Jakob.

-----Original Message-----
From: Chris Hall [mailto:[email-masked]] 
Sent: Friday, January 24, 2014 12:23 PM

The draft is silent on whether BoRR flushes old stale or restarts any existing stale-timer, whether set by GR or BoRR or otherwise -- perhaps these are intended to be implementation decisions ?

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 24 Jan 2014 15:45:26 -0500

Chris: 

[IDR co-chair hat is on]
It would be good to answer Jakob's question as we have a deployed
implementations of this protocol?  Are the problems that the implementers
should know about? 

[IDR co-chair hat off]

Sue Hares

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Friday, January 24, 2014 3:19 PM
To: Enke Chen; Chris Hall; [email-masked]
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Chris,

I think the draft, as written, works.
It's a bit hard to verify all the cases and as you can see from the email
chain, I did stumble at one point, but I can see that it all works now.

PS. your suggestion of NOT rewinding when sending BoRR before EoR does NOT
work.

Thanks,
Jakob.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Enke Chen
Sent: Friday, January 24, 2014 12:12 PM
To: Chris Hall; [email-masked]
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

No overloading of the existing semantics of EOR, please.  There have been
many lessons from even minimal and  innocent deviation of semantics (e.g.,
using empty UPDATE as EOR).

-- Enke

---

From: "Chris Hall" <[email-masked]>
Date: Fri, 24 Jan 2014 20:58:41 -0000

Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:19 +0000):
....
> Can you see something that doesn't work?

It depends on how many assumptions are made about the interaction with
GR and the initial update phase -- ie up to the EoR.

If it is assumed that:

  * the stale marking, flushing and (any) stale-timer
    are shared between Enhanced Route-Refresh and
    Graceful Restart.

  * and BoRR does not flush existing stale (particularly
    existing GR stale).

  * and the BoRR either does not restart any existing
    stale-timer, or this is explicitly an implementation
    decision.

  * and following BoRR the sender does proceed to send
    everything -- so, effectively restarts and then
    completes the initial update.

    Because otherwise the EoRR is going to flush stale
    before the initial update is complete.

  * and EoRR is sent before EoR -- so EoRR terminates
    BoRR and then EoR terminates initial update.

then (AFAICS) things do indeed work.  The EoRR is not very useful, but
does no harm -- provided it immediately precedes the EoR (which it
should do).  [Not flushing stale on EoRR in initial update state
avoids the issue.  Not sending EoRR at all in initial update state
also avoids the issue.]

I would agree that these assumptions are not deeply controversial.
But I would rather this were a matter of definition and not
assumption.  

> PS. your suggestion of NOT rewinding when sending BoRR before EoR

I didn't intend suggesting such a thing :-(

Chris

> No overloading of the existing semantics of EOR, please.  There
> have been many lessons from even minimal and  innocent deviation of
> semantics (e.g., using empty UPDATE as EOR).
> 
> -- Enke
> 
> required
> >> EORR on other hand indicates exchange of subsequent Routing
> table
> >> updates.
> >>

---

From: "Chris Hall" <[email-masked]>
Date: Sat, 25 Jan 2014 19:27:54 -0000

Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
...
> Silence means don't do it.

Hmmm.... as a principle I'm more comfortable with "that which isn't
prohibited is permitted"....

> You would definitely NOT want BoRR to flush old stales.

....but, given the definite requirement, and given that the current
precedent for "marking stale" does flush old stale, then a few words
for the avoidance of doubt ?

> Restarting the timer might be a good idea.

I dunno... a route which remains stale for "a long time" is, of
course, a candidate for being withdrawn: so having started a timer the
first time things are set stale, I would avoid extending that -- at
least for Graceful Restart, where the whole withdraw thing has been
"on-hold" since the last session failed.  For route-refresh I guess
there's more of a presumption that stale routes will be refreshed
sooner or later, and in the meantime they remain good.  So if the
route-refresh is (repeatedly) restarted for some reason, perhaps it is
more reasonable to extend the flush deadline -- but avoid doing this
indefinitely ?

FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have
built in Quagga prioritise route changes (pending changes and any that
occur during the refresh) over refresh updates.  This makes it more
likely that remaining stale routes are still good.  But the other end
cannot know that.

The paragraph in the draft discussing the "entire Adj-RIB-Out" defines
that to be the entries present "at the start of the route refresh
operation", and observes that these comprise both reachable and
unreachable routes.  [An "of" after "comprise" sets teeth on edge,
BTW.]  I'm really not sure what this paragraph is trying to tell me.
The reference to unreachable routes appears to suggest that pending
withdraws should be sent as part of the refresh -- so not left to the
EoRR to implement at the end.  The point at which the EoRR is sent is
defined such that it excludes any Adj-RIB-Out entries added after the
route-refresh started, but includes any which are changed during the
process.  It seems reasonable to delay any brand new reachable
prefixes until after all previously announced ones have been refreshed
and the EoRR sent -- if that's the intent here.  Changes which occur
before the refresh gets to a given entry are pretty naturally swept up
by the refresh.  Changes which occur after the refresh has gone past,
could/should be deferred to after the EoRR ?  Does it make a
difference if the change is a withdraw ?  (Of course MRAI may kick in
here.  Ah.  MRAI and route-refresh, there's a topic !)

I think the essence of the rule is that the EoRR should be sent once
all prefixes previously advertised to the peer as reachable have been
refreshed, ie announced or withdrawn (at least) once.  Or, perhaps
more strictly, not *before* those prefixes have *all* been announced
once -- given that the EoRR will promptly bang un-advertised stuff on
the head.  Even more strictly perhaps: not send EoRR *before* any
withdraws implied by it are required or desirable.

Depending on the implementation, a given sender may or may not be able
to determine the minimum set of updates required before sending EoRR.

If the refresh operation takes a long time, there may be good routeing
reasons to arrange for some route changes to be sent to the peer
"early" -- that is to send announcements which do not contribute to
the refresh, but which are important enough to warrant delaying the
end of the refresh.  That could be a matter for recommendation(s) in
the standard.

NB: given that the timing of the EoRR is tied to the state of the
Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions.  At
the beginning of the initial update, the Restarting and Receiving
speakers have:

  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out

  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In

Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ
part way through the initial update.  The restarting speaker responds
with BoRR, everything in its Adj-RIB-Out, and EoRR -- per
specification.  The receiving speaker sees the EoRR, and flushes
stale.  Unfortunately, if the restarting speaker has not yet fully
populated its Adj-RIB-Out, then many further routes will be sent
before the EoR falls due -- but the receiving speaker has already
flushed their tiny posteriors :-(

I am coming to the view that route-refresh during a Graceful Restart
initial update is a horse of a different colour altogether.

[So the assumption that EoRR and EoR are triggered by the same thing
was completely wrong, and I apologise for it.]

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 25 Jan 2014 19:48:25 +0000

RFCs are written for coders "practiced" in the art".
If anyone sends an EoRR before the adj-RIB-out is fully populated, then it's a BUG.
This does not need to be said.

Personally, I believe a route refresh request should not be honored until GR is complete.
Also, I don't believe a timer for the receipt of EoRR is necessary, because the EoRR is guaranteed.
Guaranteed means "unless the session drops first".
--

Jakob Heitz.

________________________________________
From: Chris Hall [[email-masked]]
Sent: Saturday, 25 January 2014 11:27 AM
To: [email-masked]
Cc: Jakob Heitz
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Chris

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 26 Jan 2014 08:17:08 +0000

After reading the analyses in this thread, my personal feeling is maybe we should avoid the interleaving between GR initial update and route refresh/enhanced route refresh, since the initial update is just sending the whole Adj-RIB-Out, there is no obvious advantage to start a route refresh/enhance route refresh during it. So a speaker should ignore the RRQ received during the initial update. Thoughts?

Best regards,
Jie

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Saturday, January 25, 2014 10:48 PM
To: Chris Hall; [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jakob Heitz.

> Silence means don't do it.

Hmmm.... as a principle I'm more comfortable with "that which isn't prohibited is permitted"....

> You would definitely NOT want BoRR to flush old stales.

....but, given the definite requirement, and given that the current precedent for "marking stale" does flush old stale, then a few words for the avoidance of doubt ?

> Restarting the timer might be a good idea.

I dunno... a route which remains stale for "a long time" is, of course, a candidate for being withdrawn: so having started a timer the first time things are set stale, I would avoid extending that -- at least for Graceful Restart, where the whole withdraw thing has been "on-hold" since the last session failed.  For route-refresh I guess there's more of a presumption that stale routes will be refreshed sooner or later, and in the meantime they remain good.  So if the route-refresh is (repeatedly) restarted for some reason, perhaps it is more reasonable to extend the flush deadline -- but avoid doing this indefinitely ?

FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have built in Quagga prioritise route changes (pending changes and any that occur during the refresh) over refresh updates.  This makes it more likely that remaining stale routes are still good.  But the other end cannot know that.

The paragraph in the draft discussing the "entire Adj-RIB-Out" defines that to be the entries present "at the start of the route refresh operation", and observes that these comprise both reachable and unreachable routes.  [An "of" after "comprise" sets teeth on edge, BTW.]  I'm really not sure what this paragraph is trying to tell me.
The reference to unreachable routes appears to suggest that pending withdraws should be sent as part of the refresh -- so not left to the EoRR to implement at the end.  The point at which the EoRR is sent is defined such that it excludes any Adj-RIB-Out entries added after the route-refresh started, but includes any which are changed during the process.  It seems reasonable to delay any brand new reachable prefixes until after all previously announced ones have been refreshed and the EoRR sent -- if that's the intent here.  Changes which occur before the refresh gets to a given entry are pretty naturally swept up by the refresh.  Changes which occur after the refresh has gone past, could/should be deferred to after the EoRR ?  Does it make a difference if the change is a withdraw ?  (Of course MRAI may kick in here.  Ah.  MRAI and route-refresh, there's a topic !)

I think the essence of the rule is that the EoRR should be sent once all prefixes previously advertised to the peer as reachable have been refreshed, ie announced or withdrawn (at least) once.  Or, perhaps more strictly, not *before* those prefixes have *all* been announced once -- given that the EoRR will promptly bang un-advertised stuff on the head.  Even more strictly perhaps: not send EoRR *before* any withdraws implied by it are required or desirable.

Depending on the implementation, a given sender may or may not be able to determine the minimum set of updates required before sending EoRR.

If the refresh operation takes a long time, there may be good routeing reasons to arrange for some route changes to be sent to the peer "early" -- that is to send announcements which do not contribute to the refresh, but which are important enough to warrant delaying the end of the refresh.  That could be a matter for recommendation(s) in the standard.

NB: given that the timing of the EoRR is tied to the state of the Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions.  At the beginning of the initial update, the Restarting and Receiving speakers have:

Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ part way through the initial update.  The restarting speaker responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification.  The receiving speaker sees the EoRR, and flushes stale.  Unfortunately, if the restarting speaker has not yet fully populated its Adj-RIB-Out, then many further routes will be sent before the EoR falls due -- but the receiving speaker has already flushed their tiny posteriors :-(

I am coming to the view that route-refresh during a Graceful Restart initial update is a horse of a different colour altogether.

[So the assumption that EoRR and EoR are triggered by the same thing was completely wrong, and I apologise for it.]

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 26 Jan 2014 09:29:20 +0000

You can definitely not ignore it, but you could postpone it.

--
Jakob Heitz.

> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <[email-masked]> wrote:
>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Sun, 26 Jan 2014 17:30:11 +0000

Jie,

I agree with Jakob. You could make it *an implementation behavior* to
postpone the route refresh reply.

Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <[email-masked]> wrote:

>> After reading the analyses in this thread, my personal feeling is maybe
>>we should avoid the interleaving between GR initial update and route
>>refresh/enhanced route refresh, since the initial update is just sending
>>the whole Adj-RIB-Out, there is no obvious advantage to start a route
>>refresh/enhance route refresh during it. So a speaker should ignore the
>>RRQ received during the initial update. Thoughts?
>> 
>> Best regards,
>> Jie
>> 
>>precedent for "marking stale" does flush old stale, then a few words for
>>the avoidance of doubt ?
>> 
>> I dunno... a route which remains stale for "a long time" is, of course,
>>a candidate for being withdrawn: so having started a timer the first
>>time things are set stale, I would avoid extending that -- at least for
>>Graceful Restart, where the whole withdraw thing has been "on-hold"
>>since the last session failed.  For route-refresh I guess there's more
>>of a presumption that stale routes will be refreshed sooner or later,
>>and in the meantime they remain good.  So if the route-refresh is
>>(repeatedly) restarted for some reason, perhaps it is more reasonable to
>>extend the flush deadline -- but avoid doing this indefinitely ?
>> 
>>unreachable routes.  [An "of" after "comprise" sets teeth on edge, BTW.]
>> I'm really not sure what this paragraph is trying to tell me.
>>process.  It seems reasonable to delay any brand new reachable prefixes
>>until after all previously announced ones have been refreshed and the
>>EoRR sent -- if that's the intent here.  Changes which occur before the
>>refresh gets to a given entry are pretty naturally swept up by the
>>refresh.  Changes which occur after the refresh has gone past,
>>could/should be deferred to after the EoRR ?  Does it make a difference
>>if the change is a withdraw ?  (Of course MRAI may kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>> 
>>refreshed, ie announced or withdrawn (at least) once.  Or, perhaps more
>>strictly, not *before* those prefixes have *all* been announced once --
>>given that the EoRR will promptly bang un-advertised stuff on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws implied
>>by it are required or desirable.
>> 
>>reasons to arrange for some route changes to be sent to the peer "early"
>>-- that is to send announcements which do not contribute to the refresh,
>>but which are important enough to warrant delaying the end of the
>>refresh.  That could be a matter for recommendation(s) in the standard.
>> 
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification.
>> The receiving speaker sees the EoRR, and flushes stale.  Unfortunately,
>>if the restarting speaker has not yet fully populated its Adj-RIB-Out,
>>then many further routes will be sent before the EoR falls due -- but
>>the receiving speaker has already flushed their tiny posteriors :-(
>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 26 Jan 2014 18:13:24 +0000

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid the complicated cases/considerations of performing route refresh during initial update:) 

For "ignore", I was thinking of scenarios in which the route refresh requirement may already be met by the initial update, while I'd admit it is hard to say...

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]] 
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postpone the route refresh reply.

Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <[email-masked]> wrote:

>> After reading the analyses in this thread, my personal feeling is 
>>maybe we should avoid the interleaving between GR initial update and 
>>route refresh/enhanced route refresh, since the initial update is just 
>>sending the whole Adj-RIB-Out, there is no obvious advantage to start 
>>a route refresh/enhance route refresh during it. So a speaker should 
>>ignore the RRQ received during the initial update. Thoughts?
>> 
>> Best regards,
>> Jie
>> 
>> Subject: Re: [Idr] WG LC for 
>> draft-ietf-idr-bgp-enhanced-route-refresh
>> 
>> Subject: RE: [Idr] WG LC for 
>> draft-ietf-idr-bgp-enhanced-route-refresh
>> 
>>least for Graceful Restart, where the whole withdraw thing has been "on-hold"
>>(repeatedly) restarted for some reason, perhaps it is more reasonable 
>>to extend the flush deadline -- but avoid doing this indefinitely ?
>> 
>> The paragraph in the draft discussing the "entire Adj-RIB-Out" 
>>defines that to be the entries present "at the start of the route 
>>refresh operation", and observes that these comprise both reachable 
>>and unreachable routes.  [An "of" after "comprise" sets teeth on edge, 
>>difference if the change is a withdraw ?  (Of course MRAI may kick in here.  Ah.
>>once -- given that the EoRR will promptly bang un-advertised stuff on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws 
>>implied by it are required or desirable.
>> 
>> Depending on the implementation, a given sender may or may not be 
>>able to determine the minimum set of updates required before sending EoRR.
>> 
>> If the refresh operation takes a long time, there may be good 
>>routeing reasons to arrange for some route changes to be sent to the peer "early"
>>-- that is to send announcements which do not contribute to the 
>>refresh, but which are important enough to warrant delaying the end of 
>>the refresh.  That could be a matter for recommendation(s) in the standard.
>> 
>> The receiving speaker sees the EoRR, and flushes stale.  
>>Unfortunately, if the restarting speaker has not yet fully populated 
>>its Adj-RIB-Out, then many further routes will be sent before the EoR 
>>falls due -- but the receiving speaker has already flushed their tiny 
>>posteriors :-(
>>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 26 Jan 2014 21:02:43 +0100

Hi Jie,

I think it actually very easy to say that initial update can not ever
guarantee that RRQ received during its sending may meet the peer's need.

Example 1:

SAFI 128 - During receiving initial update from RR to PE new VRF got added
with new RT import. Unfortunately those updates received within initial
update were already dropped as not interesting by the PE. RR must resend
full table after completed initial update. (Of course this is the case
where there is no RTC and that's why RTC helps a lot here by incremental
nature).

Example 2:

SAFI 1 - Operator has modified inbound policy on EBGP peer during
processing of incoming updates and those originally were dropped. No soft
reconfig in set.

Conclusion:

RRQ can not ever be ignored. Sure they can be delayed or batched (case of
multiple peers within the same update/peer group) sending near RRQs
(cluster of PEs got provisioned from central management station). But as
Keyur already mentioned those are rather standard local implementation
optimizations.

Question:

Does it maybe make sense to stop initial update when receiving RRQ from a
peer and start over ? Of course if peer is part of large update group it
would have to be removed dynamically from it so other members are not
delayed. In any case I think this does not impact the spec but the
implementation.

Cheers,
R.

On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) <[email-masked]>wrote:

> Hi Keyur, Jakob,
>
> Agree that "postpone" may be better. The point is we could avoid the
> complicated cases/considerations of performing route refresh during initial
> update:)
>
> For "ignore", I was thinking of scenarios in which the route refresh
> requirement may already be met by the initial update, while I'd admit it is
> hard to say...
>
>
> Best regards,
> Jie
>
> "on-hold"
> here.  Ah.
> the head.

---

From: Enke Chen <[email-masked]>
Date: Sun, 26 Jan 2014 14:56:07 -0800

Hi, Folks:

Thanks to Chris for bringing up this interesting interaction between EOR 
and EoRR.  How about the following text to address the issue:

For a BGP speaker that supports the BGP Graceful Restart specified in 
[RFC4724] , it MUST NOT send an EoRR for an AFI/SAFI to a neighbor 
before it sends the EOR for the AFI/SAFI to the neighbor.  This 
procedure would help the neighbor avoid the premature cleanup of stale 
routes.

-- Enke

---

From: Thomas Mangin <[email-masked]>
Date: Sun, 26 Jan 2014 23:25:08 +0000

+1 please do not overload or change semantic.

Thomas

Sent from my iPad

> On 24 Jan 2014, at 20:11, Enke Chen <[email-masked]> wrote:
>

---

From: Thomas Mangin <[email-masked]>
Date: Sun, 26 Jan 2014 23:39:36 +0000

Damn, time to practice then :)

Joke apart, I agree with this post. The feature should not be used ( and ignored ) until the initial route exchange has been completed.

If the session drops, I would expect the router to cancel any RR which was ongoing as the AdjRIBOut is going to be retransmitted anyway.

Thomas

Sent from my iPad

> On 25 Jan 2014, at 19:48, Jakob Heitz <[email-masked]> wrote:
>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 28 Jan 2014 19:50:42 +0000

Hi Jacob, Thomas,

Am ok with implementations delaying the servicing of route refresh
request. Enke's suggested text addresses the concern.

Best Regards,
Keyur

On 1/26/14 3:39 PM, "Thomas Mangin" <[email-masked]>
wrote:

>Joke apart, I agree with this post. The feature should not be used ( and
>ignored ) until the initial route exchange has been completed.
>
>If the session drops, I would expect the router to cancel any RR which
>was ongoing as the AdjRIBOut is going to be retransmitted anyway.
>
>Thomas
>
>Sent from my iPad
>

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 28 Jan 2014 20:06:52 +0000

Enke's text allows the order: BoRR, EoR, EoRR.

Could we change Enke's text from
"it MUST NOT send an EoRR" to 
"it MUST NOT send an BoRR"

Thanks,
Jakob.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Keyur Patel (keyupate)
Sent: Tuesday, January 28, 2014 11:51 AM
To: Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jacob, Thomas,

Am ok with implementations delaying the servicing of route refresh request. Enke's suggested text addresses the concern.

Best Regards,
Keyur

On 1/26/14 3:39 PM, "Thomas Mangin" <[email-masked]>
wrote:

>Joke apart, I agree with this post. The feature should not be used ( 
>and ignored ) until the initial route exchange has been completed.
>
>> course, a candidate for being withdrawn: so having started a timer 
>> the first time things are set stale, I would avoid extending that -- 
>> at least for Graceful Restart, where the whole withdraw thing has 
>> been "on-hold" since the last session failed.  For route-refresh I 
>> guess there's more of a presumption that stale routes will be 
>> refreshed sooner or later, and in the meantime they remain good.  So 
>> if the route-refresh is (repeatedly) restarted for some reason, 
>> perhaps it is more reasonable to extend the flush deadline -- but 
>> avoid doing this indefinitely ?
>> 
>> built in Quagga prioritise route changes (pending changes and any 
>> that occur during the refresh) over refresh updates.  This makes it 
>> more likely that remaining stale routes are still good.  But the 
>> other end cannot know that.
>> 
>> and unreachable routes.  [An "of" after "comprise" sets teeth on 
>> edge, BTW.]  I'm really not sure what this paragraph is trying to tell me.
>> prefixes until after all previously announced ones have been 
>> refreshed and the EoRR sent -- if that's the intent here.  Changes 
>> which occur before the refresh gets to a given entry are pretty 
>> naturally swept up by the refresh.  Changes which occur after the 
>> refresh has gone past, could/should be deferred to after the EoRR ?  
>> Does it make a difference if the change is a withdraw ?  (Of course 
>> MRAI may kick in here.  Ah.  MRAI and route-refresh, there's a topic 
>> !)
>> 
>> routeing reasons to arrange for some route changes to be sent to the 
>> peer "early" -- that is to send announcements which do not contribute 
>> to the refresh, but which are important enough to warrant delaying 
>> the end of the refresh.  That could be a matter for recommendation(s) 
>> in the standard.
>>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 28 Jan 2014 20:16:57 +0000

The order: BoRR, EoR, EoRR lets an implementation do both,  merge route
refresh reply with an initial table announcement or delay the route
refresh replies. As long as EoR is sent before EoRR there should be no
issue right?

Regards,
Keyur

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 28 Jan 2014 20:23:07 +0000

the order BoRR, EoR, EoRR allows this possible scenario:

Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32
The order could now be:
. start session
. send 1.1.1.1/32
. receive route refresh request.
. send BoRR
. send 2.2.2.2/32
. send EoR
. send 1.1.1.1/32
. send EoRR

On receipt of EoR, the receiver could delete stales, deleting 1.1.1.1/32.

Thanks,
Jakob.

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 12:17 PM
To: Jakob Heitz; Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

The order: BoRR, EoR, EoRR lets an implementation do both,  merge route refresh reply with an initial table announcement or delay the route refresh replies. As long as EoR is sent before EoRR there should be no issue right?

Regards,
Keyur
On 1/28/14 12:06 PM, "Jakob Heitz" <[email-masked]> wrote:

>>> all prefixes previously advertised to the peer as reachable have 
>>> been refreshed, ie announced or withdrawn (at least) once.  Or, 
>>> perhaps more strictly, not *before* those prefixes have *all* been 
>>> announced once -- given that the EoRR will promptly bang 
>>> un-advertised stuff on the head.  Even more strictly perhaps: not 
>>> send EoRR *before* any withdraws implied by it are required or desirable.
>>> 
>>> peer "early" -- that is to send announcements which do not 
>>> contribute to the refresh, but which are important enough to warrant 
>>> delaying the end of the refresh.  That could be a matter for 
>>> recommendation(s) in the standard.
>>> 
>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions.  
>>> At the beginning of the initial update, the Restarting and Receiving 
>>> speakers have:
>>> 
>>> Now suppose (bonkers or otherwise) the receiving speaker sends an 
>>> RRQ part way through the initial update.  The restarting speaker 
>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 28 Jan 2014 20:49:12 +0000

>On receipt of EoR, the receiver could delete stales, deleting 1.1.1.1/32.

Not if you use different flags/bits to mark them stale?

Implementations could choose to always postpone the route refresh reply
and get the same behavior?

Regards,
Keyur

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 28 Jan 2014 20:56:29 +0000

Could we please simplify this a bit, not to force implementations to use different stale bits?

Thanks,
Jakob.

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 12:49 PM
To: Jakob Heitz; Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

On 1/28/14 12:23 PM, "Jakob Heitz" <[email-masked]> wrote:

>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be:
>. start session
>. send 1.1.1.1/32

Implementations could choose to always postpone the route refresh reply and get the same behavior?

Regards,
Keyur

>>>If the session drops, I would expect the router to cancel any RR 
>>>which was ongoing as the AdjRIBOut is going to be retransmitted anyway.
>>>
>>>Thomas
>>>
>>>Sent from my iPad
>>>
>>>> precedent for "marking stale" does flush old stale, then a few 
>>>> words for the avoidance of doubt ?
>>>> 
>>>> the first time things are set stale, I would avoid extending that 
>>>> -- at least for Graceful Restart, where the whole withdraw thing 
>>>> has been "on-hold" since the last session failed.  For 
>>>> route-refresh I guess there's more of a presumption that stale 
>>>> routes will be refreshed sooner or later, and in the meantime they 
>>>> remain good.  So if the route-refresh is (repeatedly) restarted for 
>>>> some reason, perhaps it is more reasonable to extend the flush 
>>>> deadline -- but avoid doing this indefinitely ?
>>>> 
>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I 
>>>> have built in Quagga prioritise route changes (pending changes and 
>>>> any that occur during the refresh) over refresh updates.  This 
>>>> makes it more likely that remaining stale routes are still good.  
>>>> But the other end cannot know that.
>>>> 
>>>>withdraws should be sent as part of the refresh -- so not left to 
>>>>the EoRR to implement at the end.  The point at which the EoRR is 
>>>>sent is defined such that it excludes any Adj-RIB-Out entries added 
>>>>after the route-refresh started, but includes any which are changed 
>>>>during the process.  It seems reasonable to delay any brand new 
>>>>reachable prefixes until after all previously announced ones have 
>>>>been refreshed and the EoRR sent -- if that's the intent here.  
>>>>Changes which occur before the refresh gets to a given entry are 
>>>>pretty naturally swept up by the refresh.  Changes which occur after 
>>>>the refresh has gone past, could/should be deferred to after the EoRR ?
>>>> I think the essence of the rule is that the EoRR should be sent 
>>>>once  all prefixes previously advertised to the peer as reachable 
>>>>have  been refreshed, ie announced or withdrawn (at least) once.  
>>>>Or,  perhaps more strictly, not *before* those prefixes have *all* 
>>>>been  announced once -- given that the EoRR will promptly bang  
>>>> routeing reasons to arrange for some route changes to be sent to 
>>>> the peer "early" -- that is to send announcements which do not 
>>>> contribute to the refresh, but which are important enough to 
>>>> warrant delaying the end of the refresh.  That could be a matter 
>>>> for
>>>> At the beginning of the initial update, the Restarting and 
>>>> Receiving speakers have:
>>>> 
>>>> I am coming to the view that route-refresh during a Graceful 
>>>> Restart initial update is a horse of a different colour altogether.
>>>> 
>>>> [So the assumption that EoRR and EoR are triggered by the same 
>>>> thing was completely wrong, and I apologise for it.]
>>>> 
>>>> Chris
>>>>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 28 Jan 2014 21:08:01 +0000

Sure! I am saying you can simplify the implementation by simply delaying
the servicing of the route refresh reply till the generation of an EOR.

Question is do we allow the text to be flexible enough to cover the other
case. :)

Regards,
Keyur

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 28 Jan 2014 21:43:01 +0000

Hi Jakob, 

How about the following (based on your suggestion):

For a BGP speaker that supports the BGP Graceful Restart specified in
[RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor
before it sends the EOR for the AFI/SAFI to the neighbor.  This
procedure would help the neighbor avoid the premature cleanup of stale
routes.

This would help simplify receiver side implementation wrt GR and Enhanced
RR. :)

Regards,
Keyur

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 28 Jan 2014 22:53:38 +0000

Sold.

Thanks,
Jakob.

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 1:43 PM
To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jakob, 

For a BGP speaker that supports the BGP Graceful Restart specified in [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the AFI/SAFI to the neighbor.  This procedure would help the neighbor avoid the premature cleanup of stale routes.

This would help simplify receiver side implementation wrt GR and Enhanced RR. :)

Regards,
Keyur

On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" <[email-masked]> wrote:

>Sure! I am saying you can simplify the implementation by simply 
>delaying the servicing of the route refresh reply till the generation of an EOR.
>
>Question is do we allow the text to be flexible enough to cover the 
>other case. :)
>
>Regards,
>Keyur
>
>>>The order: BoRR, EoR, EoRR lets an implementation do both,  merge 
>>>route refresh reply with an initial table announcement or delay the 
>>>route refresh replies. As long as EoR is sent before EoRR there 
>>>should be no issue right?
>>>
>>>Regards,
>>>Keyur
>>>>>Joke apart, I agree with this post. The feature should not be used 
>>>>>( and ignored ) until the initial route exchange has been completed.
>>>>>
>>>>>> Also, I don't believe a timer for the receipt of EoRR is 
>>>>>>necessary, because the EoRR is guaranteed.
>>>>>> ....but, given the definite requirement, and given that the 
>>>>>> current precedent for "marking stale" does flush old stale, then 
>>>>>> a few words for the avoidance of doubt ?
>>>>>> 
>>>>>> course, a candidate for being withdrawn: so having started a 
>>>>>> timer the first time things are set stale, I would avoid 
>>>>>> extending that
>>>>>> routes will be refreshed sooner or later, and in the meantime 
>>>>>> they remain good.  So if the route-refresh is (repeatedly) 
>>>>>> restarted for some reason, perhaps it is more reasonable to 
>>>>>> have built in Quagga prioritise route changes (pending changes 
>>>>>> and any that occur during the refresh) over refresh updates.  
>>>>>> This makes it more likely that remaining stale routes are still good.
>>>>>>refresh operation", and observes that these comprise both 
>>>>>>reachable and unreachable routes.  [An "of" after "comprise" sets 
>>>>>>teeth on edge, BTW.]  I'm really not sure what this paragraph is 
>>>>>>trying to tell me.
>>>>>> The reference to unreachable routes appears to suggest that 
>>>>>>pending withdraws should be sent as part of the refresh -- so not 
>>>>>>left to the EoRR to implement at the end.  The point at which the 
>>>>>>EoRR is sent is defined such that it excludes any Adj-RIB-Out 
>>>>>>entries added after the route-refresh started, but includes any 
>>>>>>which are changed during the process.  It seems reasonable to 
>>>>>>delay any brand new reachable prefixes until after all previously 
>>>>>>announced ones have been refreshed and the EoRR sent -- if that's the intent here.
>>>>>>pretty naturally swept up by the refresh.  Changes which occur 
>>>>>>after the refresh has gone past, could/should be deferred to after 
>>>>>>the EoRR ?
>>>>>> Does it make a difference if the change is a withdraw ?  (Of 
>>>>>>course MRAI may kick in here.  Ah.  MRAI and route-refresh, 
>>>>>>there's a topic
>>>>>> !)
>>>>>> 
>>>>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- 
>>>>>> per specification.  The receiving speaker sees the EoRR, and 
>>>>>> flushes stale.  Unfortunately, if the restarting speaker has not 
>>>>>> yet fully populated its Adj-RIB-Out, then many further routes 
>>>>>> will be sent before the EoR falls due -- but the receiving 
>>>>>> speaker has already flushed their tiny posteriors :-(
>>>>>>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 28 Jan 2014 22:56:26 +0000

I support the wording below.

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, January 28, 2014 1:43 PM
To: "[email-masked]" <[email-masked]>, Jakob Heitz
<[email-masked]>, Thomas Mangin
<[email-masked]>, "[email-masked]"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

>>>>>>>the refresh has gone past, could/should be deferred to after the
>>>>>>>EoRR
>>>>>>>?

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 28 Jan 2014 19:52:42 -0500

Any other comments?  (support/discussion accepted)

Sue Hares

PS - Keyur - spin a draft with this change and end it to me. 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Tuesday, January 28, 2014 5:56 PM
To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, January 28, 2014 1:43 PM
To: "[email-masked]" <[email-masked]>, Jakob Heitz

>>>>>>> defines that to be the entries present "at the start of the 
>>>>>>>route refresh operation", and observes that these comprise both 
>>>>>>>after the refresh has gone past, could/should be deferred to 
>>>>>>>after the EoRR ?
>>>>>>>Or,  perhaps more strictly, not *before* those prefixes have 
>>>>>>>*all* been  announced once -- given that the EoRR will promptly 
>>>>>>>bang un-advertised stuff on the head.  Even more strictly 
>>>>>>>perhaps: not send EoRR *before* any withdraws implied by it are 
>>>>>>>required or desirable.
>>>>>>> 
>>>>>>> Depending on the implementation, a given sender may or may not 
>>>>>>>be able to determine the minimum set of updates required before 
>>>>>>>sending EoRR.
>>>>>>> 
>>>>>>> NB: given that the timing of the EoRR is tied to the state of 
>>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart
assumptions.
>>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends 
>>>>>>> an RRQ part way through the initial update.  The restarting 
>>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and 
>>>>>>> EoRR -- per specification.  The receiving speaker sees the EoRR, 
>>>>>>> and flushes stale.  Unfortunately, if the restarting speaker has 
>>>>>>> not yet fully populated its Adj-RIB-Out, then many further 
>>>>>>> routes will be sent before the EoR falls due -- but the 
>>>>>>> receiving speaker has already flushed their tiny posteriors :-(
>>>>>>>

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Wed, 29 Jan 2014 01:03:30 +0000

The draft should add a line mandating the actual semantics (instead of/in addition to the procedures of mark-and-sweep). Something along the line: 

"Any route for which no update has been sent between a BoRR and the following EoRR MUST be considered withdrawn by both the sender and the receiver."

The rest is really implementation (how to handle nested BoRR/EoRR or GR EoR, etc.), IMHO.

I support the draft, BTW.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, January 28, 2014 4:53 PM
To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas Mangin'; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Sue Hares

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Tuesday, January 28, 2014 5:56 PM
To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, January 28, 2014 1:43 PM
To: "[email-masked]" <[email-masked]>, Jakob Heitz <[email-masked]>, Thomas Mangin <[email-masked]>, "[email-masked]"
<[email-masked]>

>>delaying the servicing of the route refresh reply till the generation 
>>of
an EOR.
>>>>>>>announced ones have been refreshed and the EoRR sent -- if that's 
>>>>>>>the
intent here.
assumptions.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 28 Jan 2014 20:21:01 -0500

Saikat:

Thanks for the input, and the discussion. 

Just to be clear - We are at WG LC. We'll let Keyur take feedback for a new
version.  
And then let everyone review the changes. 

Sue 

-----Original Message-----
From: Saikat Ray (sairay) [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 8:04 PM
To: Susan Hares; 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz';
'Thomas Mangin'; [email-masked]
Cc: [email-masked]
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

The draft should add a line mandating the actual semantics (instead of/in
addition to the procedures of mark-and-sweep). Something along the line: 

"Any route for which no update has been sent between a BoRR and the
following EoRR MUST be considered withdrawn by both the sender and the
receiver."

The rest is really implementation (how to handle nested BoRR/EoRR or GR EoR,
etc.), IMHO.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, January 28, 2014 4:53 PM
To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas Mangin';
[email-masked]
Cc: [email-masked]

Sue Hares

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Tuesday, January 28, 2014 5:56 PM
To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, January 28, 2014 1:43 PM
To: "[email-masked]" <[email-masked]>, Jakob Heitz

an EOR.
intent here.
assumptions.

---

From: Thomas Mangin <[email-masked]>
Date: Wed, 29 Jan 2014 07:45:00 +0000

+1 too

Sent from my iPad

> On 28 Jan 2014, at 22:53, Jakob Heitz <[email-masked]> wrote:
> 
> Sold.
> 
> Thanks,
> Jakob.
>

---

From: Thomas Mangin <[email-masked]>
Date: Wed, 29 Jan 2014 07:50:27 +0000

Hello Saikat,

Why "both by the sender", if the route was not announced it is clearly withdrawn on the sender side and by definition if a route is not in the RR it has to be withdrawn - that said saying it can not harm ..

Thomas

Sent from my iPad

> On 29 Jan 2014, at 01:03, "Saikat Ray \(sairay\)" <[email-masked]> wrote:
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 29 Jan 2014 08:02:12 +0000

Support the new text.

Best regards,
Jie

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Keyur Patel (keyupate)
Sent: Wednesday, January 29, 2014 12:43 AM
To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jakob, 

Regards,
Keyur

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 29 Jan 2014 08:22:25 +0000

Hi Robert,

Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.

While IMO stop the initial update and start over may delay the initial convergence, and as you said  it also relates to update group processing. What do you think about the new text provided by Keyur?

Best regards,
Jie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jie,

I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending may meet the peer's need.

Example 1:

SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those updates received within initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of course this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature).

Example 2:

SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally were dropped. No soft reconfig in set.

Conclusion:

RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather standard local implementation optimizations.

Question:

Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does not impact the spec but the implementation.

Cheers,
R.

On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Keyur, Jakob,

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <[email-masked]<mailto:[email-masked]>> wrote:

>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
>>wrote:
>>
>> From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jakob Heitz
>> To: Chris Hall; [email-masked]<mailto:[email-masked]>
>> From: Chris Hall [[email-masked]<mailto:[email-masked]>]
>> To: [email-masked]<mailto:[email-masked]>
>> Cc: Jakob Heitz
>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 29 Jan 2014 10:15:01 +0100

Hi Jimmy and all,

I think Enke and Keyur's proposed text with help from Jakob makes the
behavior simplified and deterministic to hold on BoRR till first EoR is
seen.

IMHO it should be also spelled out what is the expected sequence error
handling here ... I think not following "MUST NOT" shall implicitly result
in entire session drop and complete restart ? Any error code ?

Best,
R.

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <[email-masked]>wrote:

> While IMO stop the initial update and start over may delay the initial
> convergence, and as you said  it also relates to update group processing.
> What do you think about the new text provided by Keyur?
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Sunday, January 26, 2014 11:03 PM
> *To:* Dongjie (Jimmy)
> *Cc:* Keyur Patel (keyupate); Jakob Heitz; [email-masked]
>
> *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh
>
>
>
> Hi Jie,
>
>
>
> peer "early"

---

From: <[email-masked]>
Date: Wed, 29 Jan 2014 09:51:00 +0000

Hi all,

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jimmy and all,

I think Enke and Keyur's proposed text with help from Jakob makes the behavior simplified and deterministic to hold on BoRR till first EoR is seen.

IMHO it should be also spelled out what is the expected sequence error handling here

[Bruno] +1.  And taking into account possible interaction with draft-ietf-idr-bgp-gr-notification

BTW:
"When the BGP speaker detects an error while processing a ROUTE-REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error"."

Seems a priori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more friendly way? (e.g. if BoRR is not sent following a "normal route refresh request" or if 2 BoRR are sent consecutively...)

Thanks,
Regards,
Bruno

... I think not following "MUST NOT" shall implicitly result in entire session drop and complete restart ? Any error code ?

Best,
R.

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Best regards,
Jie

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; [email-masked]<mailto:[email-masked]>

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

_________________________________________________________________________________________________________________________

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: Jakob Heitz <[email-masked]>
Date: Wed, 29 Jan 2014 15:17:06 +0000

I don't think these minor errors are worth killing a session (and all the other routes) for.
Get a BoRR, mark stale.
Get an EoRR or EoR, delete stale.
If you get two BoRR in a row, it just means the sender decided to abort a refresh and start a new one.
If in doubt, send another refresh request. You'll get another BoRR in response, so don't overdo it.

--
Jakob Heitz.

On Jan 29, 2014, at 1:51 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jimmy and all,

BTW:
“When the BGP speaker detects an error while processing a ROUTE-REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error".”

Seems a priori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more friendly way? (e.g. if BoRR is not sent following a “normal route refresh request” or if 2 BoRR are sent consecutively…)

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 29 Jan 2014 16:31:51 +0100

Hi Jakob,

I thought we are mostly talking about initial time period after the session
is established and peer did not send EOR yet. So perhaps session reset with
right error is not that bad thing to do - if for nothing else then to
signal to the peer that his sequence is wrong ?

Or maybe we should do such things in BGP Diagnostic Message ?

Best,
R.

On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz <[email-masked]>wrote:

> On Jan 29, 2014, at 1:51 AM, "[email-masked]" <
> [email-masked]> wrote:
>
>   Hi all,
>
>
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Wednesday, January 29, 2014 10:15 AM
> *To:* Dongjie (Jimmy)
> *Cc:* Keyur Patel (keyupate); [email-masked]
> handling here
> "When the BGP speaker detects an error while processing a ROUTE-REFRESH
> message with a non-zero "Message Subtype" field, it MUST send a
> NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error"."
>
>
>
> Seems a priori not inline with the recommendation from
> draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the
> consequences of error handling). Are we sure that no error condition could
> be handled in a more friendly way? (e.g. if BoRR is not sent following a
> "normal route refresh request" or if 2 BoRR are sent consecutively...)
>
>
>
> Thanks,
>
> Regards,
>
> Bruno
>
>
>
>
>
> ... I think not following "MUST NOT" shall implicitly result in entire
> session drop and complete restart ? Any error code ?
>
>
>
> Best,
> R.
>
>
>
>
>

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 29 Jan 2014 15:43:57 +0000

If you kill a session doing GR, it kills all the stale routes. It's a bad thing.

--
Jakob Heitz.

On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

I thought we are mostly talking about initial time period after the session is established and peer did not send EOR yet. So perhaps session reset with right error is not that bad thing to do - if for nothing else then to signal to the peer that his sequence is wrong ?

Best,
R.

On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz <[email-masked]<mailto:[email-masked]>> wrote:

--
Jakob Heitz.

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 29 Jan 2014 16:47:19 +0100

When the session comes up after let's say peer up there is no stale routes
.. are there ? So the whole point of GR is not to kill the routes before
timeout and lack of new complete table from a peer followed by EOR.

Perhaps we have different cases in mind ....

r.

On Wed, Jan 29, 2014 at 4:43 PM, Jakob Heitz <[email-masked]>wrote:

> On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" <[email-masked]> wrote:
>
>    Hi Jakob,
>
>  I thought we are mostly talking about initial time period after the
> session is established and peer did not send EOR yet. So perhaps session
> reset with right error is not that bad thing to do - if for nothing else
> then to signal to the peer that his sequence is wrong ?
>
>> SAFI 128 - During receiving initial update from RR to PE new VRF got
>> added with new RT import. Unfortunately those updates received within
>> initial update were already dropped as not interesting by the PE. RR must
>> resend full table after completed initial update. (Of course this is the
>> case where there is no RTC and that's why RTC helps a lot here by
>> incremental nature).
>>
>>
>>
>> Example 2:
>>
>>
>>

---

From: <[email-masked]>
Date: Wed, 29 Jan 2014 15:53:59 +0000

Hi Robert, all

>  if for nothing else then to signal to the peer that his sequence is wrong ?

Let's not send a NOTIFICATION just for logging purpose. This seems overkill to me.
For iBGP sessions, logging the error is probably enough.
For eBGP sessions, a BGP diagnostic message may be a good channel.

However, the requirement for error signaling seems lower for bgp-enhanced-route-refresh compared to idr-error-handling (where the errors may be more significant from routing correctness point of view)

Regards,
Bruno

>From: Robert Raszuk >Sent: Wednesday, January 29, 2014 4:32 PM
>
>Hi Jakob,
>
>right error is not that bad thing to do - if for nothing else then to signal
>to the peer that his sequence is wrong ?
>
>On Jan 29, 2014, at 1:51 AM, "[email-masked]"
><[email-masked]> wrote:
>Hi all,
>
>
>message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION
>message with Error Code "ROUTE-REFRESH Message Error"."
>
>Seems a priori not inline with the recommendation from draft-ietf-grow-ops-
>reqs-for-bgp-error-handling (which is to limit the consequences of error
>handling). Are we sure that no error condition could be handled in a more
>friendly way? (e.g. if BoRR is not sent following a "normal route refresh
>request" or if 2 BoRR are sent consecutively.)
>
>Thanks,
>Regards,
>Bruno
>
>
>full table after completed initial update. (Of course this is the case where
>there is no RTC and that's why RTC helps a lot here by incremental nature).
>
>Example 2:
>
>SAFI 1 - Operator has modified inbound policy on EBGP peer during processing
>of incoming updates and those originally were dropped. No soft reconfig in
>set.
>
>Conclusion:
>
>multiple peers within the same update/peer group) sending near RRQs (cluster
>of PEs got provisioned from central management station). But as Keyur
>already mentioned those are rather standard local implementation
>optimizations.
>
>Question:
>
>____________________________________________________________________________
>_____________________________________________
>
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 29 Jan 2014 15:54:38 +0000

The case I have in mind:
I restarted. You retained my routes and marked them stale.
You send some sequence of BoRR and EoRR that I consider an error.
I send you NOTIFICATION.
You delete all my stale routes.

--
Jakob Heitz.

On Jan 29, 2014, at 7:47 AM, "Robert Raszuk" <[email-masked]<mailto:[email-masked]>> wrote:

When the session comes up after let's say peer up there is no stale routes .. are there ? So the whole point of GR is not to kill the routes before timeout and lack of new complete table from a peer followed by EOR.

r.

On Wed, Jan 29, 2014 at 4:43 PM, Jakob Heitz <[email-masked]<mailto:[email-masked]>> wrote:
If you kill a session doing GR, it kills all the stale routes. It's a bad thing.

--
Jakob Heitz.

Hi Jakob,

Best,
R.

--
Jakob Heitz.

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 29 Jan 2014 17:30:30 +0000

The receiver should simply ignore (with logging an error) BORRs and EORRs before the receipt of EOR.

Regards,
Keyur

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Wed, 29 Jan 2014 10:15:01 +0100
To: "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
Cc: Keyur Patel <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jimmy and all,

IMHO it should be also spelled out what is the expected sequence error handling here ... I think not following "MUST NOT" shall implicitly result in entire session drop and complete restart ? Any error code ?

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

---

From: Thomas Mangin <[email-masked]>
Date: Wed, 29 Jan 2014 19:58:25 +0000

This would be the simplest solution.
And ignore EoRR which have no BeRR associated (for the case BoRR EoR EoRR).

Thomas

On 29 Jan 2014, at 17:30, Keyur Patel (keyupate) <[email-masked]> wrote:

> From: Robert Raszuk <[email-masked]>
> To: "Dongjie (Jimmy)" <[email-masked]>
> Cc: Keyur Patel <[email-masked]>, Jakob Heitz <[email-masked]>, "[email-masked]" <[email-masked]>
> On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <[email-masked]> wrote:
>> Hi Robert,
>>  
>> On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) <[email-masked]> wrote:
>> Hi Keyur, Jakob,
>>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 29 Jan 2014 22:16:01 +0000

Hi Bruno,

We only generate Notification for invalid length. Apologies for the confusion. Attached is the revised text.

Regards,
Keyur

<snip>
The error handling specified in this section is applicable only when
   a BGP speaker has received the "Enhanced Route Refresh Capability"
   from a peer.

   If the length, excluding the fixed-size message header, of the
   received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4,
   then the BGP speaker MUST send a NOTIFICATION message with the Error
   Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid
   Message Length".  The Data field of the NOTIFICATION message MUST
   contain the complete ROUTE-REFRESH message.

   When the BGP speaker receives a ROUTE-REFRESH message with a "Message
   Subtype" field other than 1 or 2, it MUST ignore the received ROUTE-
   REFRESH message.  It SHOULD log an error for further analysis.

<snip>

From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, 29 Jan 2014 09:51:00 +0000
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Keyur Patel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; [email-masked]<mailto:[email-masked]>

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Thu, 30 Jan 2014 01:38:17 +0000

The route may have been advertised before (and not (yet) withdrawn). Consider the example:

+---+     +---+

| A +-----+ B |

+---+     +---+

t=0: A sends three prefixes: 1.1.1.1/32, 2.2.2.2/32, 3.3.3.3/32, to B.

t=1: B sends an (enhanced) route-refresh request to A.

t=2: A sends BoRR to B.

t=3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B

t=4: A sends EoRR to B.

At this point, both A and B MUST treat 3.3.3.3/32 as withdrawn even though there was no explicit withdraw sent for it. That means, A doesn't need to send an explicit withdraw for 3.3.3.3/32, and B must delete 3.3.3.3/32's path from A.

This is the core semantics of BoRR and EoRR and it takes care of all cases. This implies, e.g., if the sender A want to ensure that a particular prefix, x.y.z.w/n, is not considered withdrawn by the receiver, then A MUST advertise x.y.z.w/n following any BoRR (even in nested cases) *before* any EoRR.

-----Original Message-----
From: Thomas Mangin [mailto:[email-masked]]
Sent: Tuesday, January 28, 2014 11:50 PM
To: Saikat Ray (sairay)
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; [email-masked]; [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hello Saikat,

Thomas

Sent from my iPad

> On 29 Jan 2014, at 01:03, "Saikat Ray \(sairay\)" <[email-masked]<mailto:[email-masked]>> wrote:

> To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas

> Mangin'; [email-masked]<mailto:[email-masked]>

> To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin;

> [email-masked]<mailto:[email-masked]>

> From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, Thomas Mangin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"

> <[email-masked]<mailto:[email-masked]>>

>> procedure would help the neighbor avoid the premature cleanup of

>> stale routes.

>> This would help simplify receiver side implementation wrt GR and

>> Enhanced RR. :)

>>> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>> wrote:

>>> delaying the servicing of the route refresh reply till the

>>> generation of

>>>> On 1/28/14 12:56 PM, "Jakob Heitz" <[email-masked]<mailto:[email-masked]>> wrote:

>>>> Could we please simplify this a bit, not to force implementations

>>>> to use different stale bits?

>>>> To: Jakob Heitz; Thomas Mangin; [email-masked]<mailto:[email-masked]>

>>>>> On 1/28/14 12:23 PM, "Jakob Heitz" <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> On receipt of EoR, the receiver could delete stales, deleting

>>>>> 1.1.1.1/32.

>>>> Implementations could choose to always postpone the route refresh

>>>> reply and get the same behavior?

>>>>> To: Jakob Heitz; Thomas Mangin; [email-masked]<mailto:[email-masked]>

>>>>> route refresh reply with an initial table announcement or delay

>>>>> the route refresh replies. As long as EoR is sent before EoRR

>>>>> there should be no issue right?

>>>>>> On 1/28/14 12:06 PM, "Jakob Heitz" <[email-masked]<mailto:[email-masked]>> wrote:

>>>>>> From: Idr [mailto:[email-masked]] On Behalf Of Keyur Patel

>>>>>> (keyupate)

>>>>>> To: Thomas Mangin; [email-masked]<mailto:[email-masked]>

>>>>>> Am ok with implementations delaying the servicing of route

>>>>>> refresh request. Enke's suggested text addresses the concern.

>>>>>> On 1/26/14 3:39 PM, "Thomas Mangin"

>>>>>> <[email-masked]<mailto:[email-masked]>>

>>>>>>> Joke apart, I agree with this post. The feature should not be

>>>>>>> used ( and ignored ) until the initial route exchange has been completed.

>>>>>>> which was ongoing as the AdjRIBOut is going to be retransmitted

>>>>>>> anyway.

>>>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz

>>>>>>>> <[email-masked]<mailto:[email-masked]>>

>>>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully

>>>>>>>> populated, then it's a BUG.

>>>>>>>> Personally, I believe a route refresh request should not be

>>>>>>>> honored until GR is complete.

>>>>>>>> Hmmm.... as a principle I'm more comfortable with "that which

>>>>>>>> isn't prohibited is permitted"....

>>>>>>>> current precedent for "marking stale" does flush old stale,

>>>>>>>> then a few words for the avoidance of doubt ?

>>>>>>>> -- at least for Graceful Restart, where the whole withdraw

>>>>>>>> thing has been "on-hold" since the last session failed.  For

>>>>>>>> This makes it more likely that remaining stale routes are still

> good.

>>>>>>>> reachable and unreachable routes.  [An "of" after "comprise"

>>>>>>>> sets teeth on edge, BTW.]  I'm really not sure what this

>>>>>>>> paragraph is trying to tell me.

>>>>>>>> pending withdraws should be sent as part of the refresh -- so

>>>>>>>> not left to the EoRR to implement at the end.  The point at

>>>>>>>> which the EoRR is sent is defined such that it excludes any

>>>>>>>> Adj-RIB-Out entries added after the route-refresh started, but

>>>>>>>> includes any which are changed during the process.  It seems

>>>>>>>> reasonable to delay any brand new reachable prefixes until

>>>>>>>> after all previously announced ones have been refreshed and the

>>>>>>>> EoRR sent -- if that's the

>>>>>>>> Changes which occur before the refresh gets to a given entry

>>>>>>>> are pretty naturally swept up by the refresh.  Changes which

>>>>>>>> occur after the refresh has gone past, could/should be deferred

>>>>>>>> to after the EoRR ?

>>>>>>>> once  all prefixes previously advertised to the peer as

>>>>>>>> reachable have  been refreshed, ie announced or withdrawn (at least) once.

>>>>>>>> routeing reasons to arrange for some route changes to be sent

>>>>>>>> to the peer "early" -- that is to send announcements which do

>>>>>>>> not contribute to the refresh, but which are important enough

>>>>>>>> to warrant delaying the end of the refresh.  That could be a

>>>>>>>> matter for

>>>>>>>> EoRR -- per specification.  The receiving speaker sees the

>>>>>>>> EoRR, and flushes stale.  Unfortunately, if the restarting

>>>>>>>> speaker has not yet fully populated its Adj-RIB-Out, then many

>>>>>>>> further routes will be sent before the EoR falls due -- but the

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 30 Jan 2014 01:52:46 +0000

Yes Saikat, but...

The intent is to verify the routing table that was supposed to have been built with proper update messages.
If an EoRR deletes an unexpected stale route, it should be logged and debugged. Notwithstanding routes deleted by policy changes.
For example, we should not invent a mass withdraw procedure like sending BoRR followed directly by EoRR without any intervening update messages.
I can see a few people gagging now :)

Thanks,
Jakob.

From: Saikat Ray (sairay) [mailto:[email-masked]]
Sent: Wednesday, January 29, 2014 5:38 PM
To: Thomas Mangin
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; [email-masked]; [email-masked]
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

+---+     +---+

| A +-----+ B |

+---+     +---+

t=2: A sends BoRR to B.

t=4: A sends EoRR to B.

-----Original Message-----
From: Thomas Mangin [mailto:[email-masked]]
Sent: Tuesday, January 28, 2014 11:50 PM
To: Saikat Ray (sairay)
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hello Saikat,

Thomas

Sent from my iPad

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Thu, 30 Jan 2014 02:06:13 +0000

From: Jakob Heitz [mailto:[email-masked]]
Sent: Wednesday, January 29, 2014 5:53 PM
To: Saikat Ray (sairay); Thomas Mangin
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); [email-masked]; [email-masked]
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Yes Saikat, but...

The intent is to verify the routing table that was supposed to have been built with proper update messages.
If an EoRR deletes an unexpected stale route, it should be logged and debugged.

[SR] No disagreement there. My only point was that the draft should codify the semantics of BoRR/EoRR so that implementations can make all corner cases work correctly, instead of (or in addition to) discussing these corner cases.

Notwithstanding routes deleted by policy changes.
For example, we should not invent a mass withdraw procedure like sending BoRR followed directly by EoRR without any intervening update messages.

[SR] Well, it has already been invented by BoRR/EoRR ;) Perhaps the draft can beg the implementers to not use this WMD (or threaten them with syslogs) :D

Thanks,
Jakob.

+---+     +---+

| A +-----+ B |

+---+     +---+

t=2: A sends BoRR to B.

t=4: A sends EoRR to B.

-----Original Message-----
From: Thomas Mangin [mailto:[email-masked]]
Sent: Tuesday, January 28, 2014 11:50 PM
To: Saikat Ray (sairay)
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hello Saikat,

Thomas

Sent from my iPad

---

From: Thomas Mangin <[email-masked]>
Date: Thu, 30 Jan 2014 07:27:01 +0000

Hello Sairay,

Thank you for taking the time to put this flow together. Appreciated. This is how I understood the router behaviour too. What I was questioning was the need to have the word "sender" in the sentence.

The following wording should cover this case IMHO :

"Any route for which no update has been sent between a BoRR and the following EoRR MUST be considered withdrawn by the receiver" or even shorter
"Any route for which no update has been sent between a BoRR and the following EoRR MUST be considered withdrawn"

I was trying to understand why you felt the need to specify the sender, where the route is already withdrawn as the RR did not contain it ...

Thomas

On 30 Jan 2014, at 01:38, Saikat Ray (sairay) <[email-masked]> wrote:

> At this point, both A and B MUST treat 3.3.3.3/32 as withdrawn even though there was no explicit withdraw sent for it. That means, A doesn’t need to send an explicit withdraw for 3.3.3.3/32, and B must delete 3.3.3.3/32’s path from A.
>  
> > Mangin'; [email-masked]
> > Cc: [email-masked]
> >>>>>> <[email-masked]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>>> <[email-masked]>
> >>>>>>>> wrote:
> >>>>>>>>

---

From: <[email-masked]>
Date: Thu, 30 Jan 2014 10:27:56 +0000

Hi Keyur,

Thanks for your reply.
Your proposed new text, using NOTIFICATION only for syntax errors seems much better to me. Thanks for the clarification.

Ideally, in addition, I would prefer to have a text also covering other types of errors. At least the violation of explicit statement in the draft. E.g. for the following 2 MUST
"   Before the speaker starts a route refresh that is either initiated
   locally, or in response to a "normal route refresh request" from the
   peer, the speaker MUST send a BoRR message.  After the speaker
   completes the re-advertisement of the entire Adj-RIB-Out to the peer,
   it MUST send an EoRR message."

Regarding the first one, IMHO there is no harm if the MUST is not enforced. One option may be :s/MUST/SHOULD; or a statement in § "Error handling" on how to handle this error (e.g. log and nothing else).
Regarding the second one, I'd like to see a text specifying what should be done when I receive two BoRR. E.g.
-a- consider that the second BoRR should be considered as a EoRR+ BoRR
-b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE when the second EoRR is received)
-c- ignore the second EoRR.

(plus obviously log the error in all cases)

"a" sounds dangerous to me.
"b" should a priori ok (accept a small error but consider that the speaker remember (and acted as per) its latest message.)
"c" is the safest path (there is a error, I don't know what it is so I take the safest option)

Considering the motivation for this draft (enhance BGP robustness, but not bring a new feature), I think I would prefer "c" which is the more robust. Especially given that if the receiver has a doubt, I has a way to clear it by sending a new Route Refresh message.
But I guess I would be fine with "b" if you/the WG have a different opinion.
(My understanding of the current draft, is that "b" is expected, but in all cases I would prefer a specific text in  § "Error handling")

Thanks,
Cheers,
Bruno

From: Keyur Patel (keyupate) [mailto:[email-masked]]
Sent: Wednesday, January 29, 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; Robert Raszuk
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Bruno,

Regards,
Keyur

<snip>

<snip>

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

Thank you.

---

From: "Chris Hall" <[email-masked]>
Date: Thu, 30 Jan 2014 12:16:03 -0000

Jakob Heitz wrote (on Thu 30-Jan-2014 at 01:53 +0000):
.....
> If an EoRR deletes an unexpected stale route, it should be logged
> and debugged. Notwithstanding routes deleted by policy changes.

This puts an onus on the sender to send unreachable as well as
reachable advertisements for all prefixes believed known by the
receiver.  And hence... although on EoRR the receiver MUST withdraw
anything not mentioned since the BoRR, the sender SHOULD/MUST NOT
depend on that as a means to withdraw prefixes. 

Chris

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 30 Jan 2014 14:48:04 +0000

Hi Bruno,

Comments Inlined #Keyur.

From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, 30 Jan 2014 10:27:56 +0000
To: Keyur Patel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Keyur,

Thanks for your reply.

Ideally, in addition, I would prefer to have a text also covering other types of errors. At least the violation of explicit statement in the draft. E.g. for the following 2 MUST
“   Before the speaker starts a route refresh that is either initiated
   locally, or in response to a "normal route refresh request" from the
   peer, the speaker MUST send a BoRR message.  After the speaker
   completes the re-advertisement of the entire Adj-RIB-Out to the peer,
   it MUST send an EoRR message.”

Regarding the first one, IMHO there is no harm if the MUST is not enforced. One option may be :s/MUST/SHOULD; or a statement in § “Error handling” on how to handle this error (e.g. log and nothing else).
Regarding the second one, I’d like to see a text specifying what should be done when I receive two BoRR. E.g.
-a- consider that the second BoRR should be considered as a EoRR+ BoRR
-b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE when the second EoRR is received)
-c- ignore the second EoRR.

#Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table announcement. The second EoRR will be essentially no-op (I.e C case). Implementations can log the no-op behavior.

Regards,
Keyur

“a” sounds dangerous to me.
“b” should a priori ok (accept a small error but consider that the speaker remember (and acted as per) its latest message.)
“c” is the safest path (there is a error, I don’t know what it is so I take the safest option)

Considering the motivation for this draft (enhance BGP robustness, but not bring a new feature), I think I would prefer “c” which is the more robust. Especially given that if the receiver has a doubt, I has a way to clear it by sending a new Route Refresh message.
But I guess I would be fine with “b” if you/the WG have a different opinion.
(My understanding of the current draft, is that “b” is expected, but in all cases I would prefer a specific text in  § “Error handling”)

Thanks,
Cheers,
Bruno

Hi Bruno,

Regards,
Keyur

<snip>

<snip>

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

Thank you.

---

From: <[email-masked]>
Date: Thu, 30 Jan 2014 16:42:39 +0000

Hi Keyur,

Comments inlined #Bruno

From: Keyur Patel (keyupate) [mailto:[email-masked]]
Sent: Thursday, January 30, 2014 3:48 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Bruno,

Comments Inlined #Keyur.

Hi Keyur,

Thanks for your reply.

#Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table announcement. The second EoRR will be essentially no-op (I.e C case). Implementations can log the no-op behavior.
#Bruno : well we don't really know what it means for the sender because it was not supposed to do this in the first place, so it's a bug.

Ok for your proposition to ignore the second EoRR. Would it be possible to add this sentence/point in the § "Error handling?" Especially since this seems to contradict the spec  which seems more on the side of "b": "When
   a BGP speaker receives a BoRR message from a peer, it MUST mark all
   the routes with the given <AFI, SAFI> from that peer as stale."
Thanks,
Regards,
Bruno

Regards,
Keyur

Thanks,
Cheers,
Bruno

Hi Bruno,

Regards,
Keyur

<snip>

<snip>

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

Thank you.

Thank you.

---

From: "Chris Hall" <[email-masked]>
Date: Thu, 30 Jan 2014 17:05:46 -0000

Bruno Decraene wrote (on Thu 30-Jan-2014 at 10:28 +0000):
....
> Regarding the second one, I’d like to see a text specifying what
> should be done when I receive two BoRR. E.g.

In the (however unlikely) case of both ends deciding to trigger a
route-refresh at roughly the same time, it is possible for a BoRR and
an RRQ (route-refresh-request) to cross.

By rule, a BoRR must be sent in response to RRQ: starting or
_restarting_ route-refresh.  So, a second BoRR is not necessarily an
error, at least after sending RRQ.

Moreover, as I understand it, the intention is that either end can not
only start but also restart a route-refresh, at any time.  Which makes
two (or more) BoRR without an intervening EoRR, by definition, OK.
Further, as I understand it, a refresh operation may be restarted any
number of times, sending BoRR any number of times, terminated by a
single EoRR.

Now, by way of an exception, we have GR Initial Update "mode".  This
looks much as if the two ends have sent each other a "virtual BoRR",
to be terminated by an actual EoR.  But, in this case, if either end
sends an RRQ, the plan is for the other to hold up the BoRR response
until after the EoR is sent.  And (I assume) if either feels moved to
do a route-refresh during the Initial Update, it must hold in the BoRR
until after the EoR -- making BoRR before EoR an error.  [Both ends
could be required to hold in an RRQ until after EoR... but I'm not
sure where the rules are stating the expected/proper behaviour, and
where they are intended to "just work" for both expected and
unexpected/improper messages.  I guess it's "obvious" that multiple
RRQs can be responded to by one BoRR ?]

Just exploring the possibilities... I suppose this approach could be
extended to route-refresh: so that after BoRR and before EoRR, the
sender holds up an incoming RRQ, and holds in any impulse to restart
the route-refresh itself.  So that:

  * BoRR and EoRR would, indeed, be brackets.

    As you say, this would imply some to-be-defined error 
    handling for BoRR during route-refresh or during GR 
    Initial Update -- in addition to the error handling for 
    EoRR not during route-refresh.  [I guess the error 
    handling for an unexpected EoR is to ignore it.]

  * if either end were to decide that a route-refresh was
    required part way through an existing route-refresh or 
    an initial update, then everything sent from that moment
    up to the EoRR/EoR would be a waste of time and effort.

    On the other hand, it would also mean that a route-
    refresh and initial update could not be endlessly 
    extended by repeated BoRR/RRQ.

  * the handling of route-refresh and initial update would be
    consistent -- for what that's worth.

FWIW: I think that when a route-refresh is required, it should be
started as soon as possible.  Suppose an initial update is half way
through sending 300,000 routes, and a route-refresh becomes needed:
holding up the refresh until after the EoR means that 150,000 routes
will be repeated, unnecessarily.  At the Restarting Speaker end,
delaying EoR may delay route-selection.  On the other hand, if the
route-refresh is delayed and starts immediately after the EoR,
route-selection starts with 300,000 stale routes on its hands.  You
win some, you lose some... but on balance, ploughing on with a
route-refresh or initial update, when a new route-refresh is required,
feels wrong to me.

However, these cases are screamingly unlikely, so provided that the
eventualities are clearly covered -- requiring the minimum of extra
mechanism and/or error handling (code) -- the price of cocoa is
unaffected.

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 30 Jan 2014 17:26:12 +0000

Then make it not a bug.
A second BoRR means the first one was aborted. The draft as it stands already covers this case.

--
Jakob Heitz.

On Jan 30, 2014, at 8:43 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Keyur,

Comments inlined #Bruno

Hi Bruno,

Comments Inlined #Keyur.

Hi Keyur,

Thanks for your reply.

#Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table announcement. The second EoRR will be essentially no-op (I.e C case). Implementations can log the no-op behavior.
#Bruno : well we don’t really know what it means for the sender because it was not supposed to do this in the first place, so it’s a bug.

Ok for your proposition to ignore the second EoRR. Would it be possible to add this sentence/point in the § “Error handling?” Especially since this seems to contradict the spec  which seems more on the side of “b”: “When
   a BGP speaker receives a BoRR message from a peer, it MUST mark all
   the routes with the given <AFI, SAFI> from that peer as stale.”
Thanks,
Regards,
Bruno

Regards,
Keyur

Thanks,
Cheers,
Bruno

Hi Bruno,

Regards,
Keyur

<snip>

<snip>

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

Thank you.

Thank you.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 30 Jan 2014 17:38:43 +0000

Hi Bruno,

Agree with Jakob here. :) The Route Refresh could restart for various reasons (and depending on implementations). In that scenario, it could simply resend a BoRR again. The receiver side behavior doesn't change in such a case. Upon a receipt of BoRR mark the routes stale and restart the timer.

Having said that implementations could log the receipt of such back-to-back BoRRs or EoRRs for further analysis. But it doesn't look like a Bug.

Regards,
Keyur

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Thu, 30 Jan 2014 17:26:12 +0000
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Keyur Patel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Then make it not a bug.

--
Jakob Heitz.

Hi Keyur,

Comments inlined #Bruno

Hi Bruno,

Comments Inlined #Keyur.

From:<[email-masked]<mailto:[email-masked]>>

Hi Keyur,

Thanks for your reply.

Regards,
Keyur

Thanks,
Cheers,
Bruno

Hi Bruno,

Regards,
Keyur

<snip>

<snip>

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

Thank you.

Thank you.

---

From: "Dickson, Brian" <[email-masked]>
Date: Thu, 30 Jan 2014 17:55:25 +0000

I think there may need to be something akin to a state machine diagram, just so everything is crystal clear to all current and future implementers.

I don't think it would be too complex, but should handle the cases discussed.

Just my opinion, feel free to ignore. However, the discussion during LC would suggest that such a diagram might be helpful.

Brian

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 30, 2014 12:26 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Then make it not a bug.

--
Jakob Heitz.

Hi Keyur,

Comments inlined #Bruno

Hi Bruno,

Comments Inlined #Keyur.

Hi Keyur,

Thanks for your reply.

Regards,
Keyur

Thanks,
Cheers,
Bruno

Hi Bruno,

Regards,
Keyur

<snip>

<snip>

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

Thank you.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Jan 2014 19:05:10 +0100

All,

Do we really need to get stuck forever and worry about differences with
both EoR and EoRR ?

Would it be much simpler to define Begin_of_RIB BOR and End_of_RIB EOR
(already defined in GR spec) and always use both when peers negotiate
enhanced route refresh even for the initial update with GR or as response
to RRQ ?

Is there any case where EoRR has added meaning on top of otherwise sent EOR
?

Maybe this questions comes late considering deployed implementations, but I
guess it is better late then never :)

Best,
R.

On Thu, Jan 30, 2014 at 6:38 PM, Keyur Patel (keyupate)
<[email-masked]>wrote:

>  Hi Bruno,
>
>  Agree with Jakob here. :) The Route Refresh could restart for various
> reasons (and depending on implementations). In that scenario, it could
> simply resend a BoRR again. The receiver side behavior doesn't change in
> such a case. Upon a receipt of BoRR mark the routes stale and restart the
> timer.
>
>  Having said that implementations could log the receipt of such
> back-to-back BoRRs or EoRRs for further analysis. But it doesn't look like
> a Bug.
>
>  Regards,
> Keyur
>
>   From: Jakob Heitz <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Keyur Patel <[email-masked]>, "[email-masked]" <[email-masked]>
>
> On Jan 30, 2014, at 8:43 AM, "[email-masked]" <
> *From:* Keyur Patel (keyupate) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Thursday, January 30, 2014 3:48 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked]
> *From:*<[email-masked]>
> *Date: *Thu, 30 Jan 2014 10:27:56 +0000
> *To: *Keyur Patel <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh
>
>
>
> Hi Keyur,
>
>
>
> Thanks for your reply.
>
> Your proposed new text, using NOTIFICATION only for syntax errors seems
> much better to me. Thanks for the clarification.
>
>
>
> Ideally, in addition, I would prefer to have a text also covering other
> types of errors. At least the violation of explicit statement in the draft.
> E.g. for the following 2 MUST
>
> Regarding the first one, IMHO there is no harm if the MUST is not
> enforced. One option may be :s/MUST/SHOULD; or a statement in § "Error
> handling" on how to handle this error (e.g. log and nothing else).
>
> #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means
> it has aborted the first route refresh table announcement and restarted the
> route refresh table announcement. The second EoRR will be essentially no-op
> (I.e C case). Implementations can log the no-op behavior.
>
> #Bruno : well we don't really know what it means for the sender because it
> was not supposed to do this in the first place, so it's a bug.
>
> "b" should a priori ok (accept a small error but consider that the speaker
> remember (and acted as per) its latest message.)
>
> Considering the motivation for this draft (enhance BGP robustness, but not
> bring a new feature), I think I would prefer "c" which is the more robust.
> Especially given that if the receiver has a doubt, I has a way to clear it
> by sending a new Route Refresh message.
>
> (My understanding of the current draft, is that "b" is expected, but in
> all cases I would prefer a specific text in  § "Error handling")
>
>
>
> Thanks,
>
> Cheers,
>
> Bruno
>
>
>
>
>
> *From:* Keyur Patel (keyupate) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Wednesday, January 29, 2014 11:16 PM
> *To:* DECRAENE Bruno IMT/OLN; Robert Raszuk
> *Cc:* [email-masked]
> *From: *<[email-masked]>
> *Date: *Wed, 29 Jan 2014 09:51:00 +0000
> *To: *Robert Raszuk <[email-masked]>, Keyur Patel <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh
>
>
>
> Hi all,
>
>
>
>
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk

---

From: Thomas Mangin <[email-masked]>
Date: Thu, 30 Jan 2014 18:27:34 +0000

On 30 Jan 2014, at 18:05, Robert Raszuk <[email-masked]> wrote:

> Maybe this questions comes late considering deployed implementations, but I guess it is better late then never :) 

Can someone tell us how the current implementation deal with with the scenario discussed ?

ExaBGP will honour the RR request once the initial table dump / GR is done and the EoR was sent. It delays the reply until that point then send the BoRR / updates / EoRR.
If multiple RR for the same family or not are received, the successive RR are ignored, until the RIB transfer is completed

When sending a RR, as the RIB implementation is left to the user and no reference RIB code exists today, the problem to deal with the incoming B/EoRR is left to the RIB implementation.

Thomas

---

From: <[email-masked]>
Date: Fri, 31 Jan 2014 08:35:01 +0000

Hi Keyur, Jakob, Chris,

Thanks for the clarification. I had missed the sentence stating that BoRR can be sent _any_ time. (so including multiple consecutive ones)
Please disregard my last comments.

Bruno

From: Keyur Patel (keyupate) [mailto:[email-masked]]
Sent: Thursday, January 30, 2014 6:39 PM
To: Jakob Heitz; DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Bruno,

Regards,
Keyur

Then make it not a bug.

--
Jakob Heitz.

Comments inlined #Bruno

Hi Bruno,

Comments Inlined #Keyur.

Hi Keyur,

Thanks for your reply.

Regards,
Keyur

Thanks,
Cheers,
Bruno

Hi Bruno,

Regards,
Keyur

<snip>

<snip>

Hi all,

Hi Jimmy and all,

BTW:

Thanks,
Regards,
Bruno

Best,
R.

Best regards,
Jie

Hi Jie,

Example 1:

Example 2:

Conclusion:

Question:

Cheers,
R.

Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

Regards,
Keyur

Thank you.

Thank you.

Thank you.