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

[Robert Raszuk <[e-mail]>]

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)
<[e-mail]>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 <[e-mail]>
> Date: Thu, 30 Jan 2014 17:26:12 +0000
> To: "[e-mail]" <[e-mail]>
> Cc: Keyur Patel <[e-mail]>, "[e-mail]" <[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]" <
> [e-mail]> wrote:
>
>   Hi Keyur,
>
>
>
> Comments inlined #Bruno
>
>
>
> *From:* Keyur Patel (keyupate) [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Thursday, January 30, 2014 3:48 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [e-mail]
> *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh
>
>
>
> Hi Bruno,
>
>
>
> Comments Inlined #Keyur.
>
>
>
> *From:*<[e-mail]>
> *Date: *Thu, 30 Jan 2014 10:27:56 +0000
> *To: *Keyur Patel <[e-mail]>
> *Cc: *"[e-mail]" <[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]<[e-mail]>]
>
> *Sent:* Wednesday, January 29, 2014 11:16 PM
> *To:* DECRAENE Bruno IMT/OLN; Robert Raszuk
> *Cc:* [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]>
> *Date: *Wed, 29 Jan 2014 09:51:00 +0000
> *To: *Robert Raszuk <[e-mail]>, Keyur Patel <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh
>
>
>
> Hi all,
>
>
>
>
>
> *From:* Idr [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Wednesday, January 29, 2014 10:15 AM
> *To:* Dongjie (Jimmy)
> *Cc:* Keyur Patel (keyupate); [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]>
> 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]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Sunday, January 26, 2014 11:03 PM
> *To:* Dongjie (Jimmy)
> *Cc:* Keyur Patel (keyupate); Jakob Heitz; [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]>
> 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]]
> Sent: Sunday, January 26, 2014 8:30 PM
> To: Jakob Heitz; Dongjie (Jimmy)
> Cc: [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]> 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]>
> >>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]] On Behalf Of Jakob Heitz
> >> Sent: Saturday, January 25, 2014 10:48 PM
> >> To: Chris Hall; [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]]
> >> Sent: Saturday, 25 January 2014 11:27 AM
> >> To: [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]
> >> https://www.ietf.org/mailman/listinfo/idr
> >_______________________________________________
> >Idr mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [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]
> https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>