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

["Keyur Patel (keyupate)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Thu, 30 Jan 2014 17:26:12 +0000
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Keyur Patel <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

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, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Keyur,

Comments inlined #Bruno

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

Hi Bruno,

Comments Inlined #Keyur.

From:<[e-mail]<mailto:[e-mail]>>
Date: Thu, 30 Jan 2014 10:27:56 +0000
To: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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
“   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.
#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

(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:[e-mail]]
Sent: Wednesday, January 29, 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; Robert Raszuk
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

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: <[e-mail]<mailto:[e-mail]>>
Date: Wed, 29 Jan 2014 09:51:00 +0000
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>, Keyur Patel <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi all,


From: Idr [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> wrote:
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:[e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; [e-mail]<mailto:[e-mail]>

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) <[e-mail]<mailto:[e-mail]>> 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

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: [e-mail]<mailto:[e-mail]>
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" <[e-mail]<mailto:[e-mail]>> wrote:

>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <[e-mail]<mailto:[e-mail]>>
>>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
>>
>> -----Original Message-----
>> From: Idr [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; [e-mail]<mailto:[e-mail]>
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> 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 [[e-mail]<mailto:[e-mail]>]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: [e-mail]<mailto:[e-mail]>
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> 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
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/idr
>_______________________________________________
>Idr mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/idr

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



_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.


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