Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[Gyan Mishra <[e-mail]>]

Hi Robert

You are mentioning RFC 5291 section 6 top of page 8 talks about
when-to-refresh immediate or deferred.



   If the When-to-refresh indicates IMMEDIATE, then after processing all
   the ORF entries carried in the message the speaker re-advertises to
   the peer routes from the Adj-RIB-Out associated with the peer that
   have the same AFI/SAFI as what is carried in the message, and taking
   into account all the ORF entries for that AFI/SAFI received from the
   peer.  The speaker MUST re-advertise all the routes that have been
   affected by the ORF entries carried in the message, but MAY also re-
   advertise the routes that have not been affected by the ORF entries
   carried in the message.

   If the When-to-refresh indicates DEFER, then after processing all the
   ORF entries carried in the message the speaker defers re-
   advertisement to the peer routes from the Adj-RIB-Out associated with
   the peer that have the same AFI/SAFI as what is carried in the
   message, and taking into account all the ORF entries received from
   the peer until the speaker receives a subsequent ROUTE-REFRESH
   message for the same AFI/SAFI either without any ORF entries, or with
   one or more ORF entries and When-to-refresh set to IMMEDIATE.


      We can add this caveat related to when to refresh to the draft.

Kind Regards

Gyan
On Mon, Aug 29, 2022 at 4:42 PM Robert Raszuk <[e-mail]> wrote:

> Gyan,
>
>
>> I am not understanding this in quotes
>>
> “ but it is still receiving new routes from the RR (RR hasn`t received and
>> processed the ORF message).”
>>
>
> In addition to what Igor kindly already illustrated, let me also add a new
> dimension to this which apparently is not obvious.
>
> ORF action can be IMMEDIATE or DEFERED.
>
> When as in your examples from section 8 you set to IMMEDIATE then you get
> a full VPN table dump after each ORF msg. Yes filtered routes may not be
> there, but you will receive all eligible routes minus those in ORF message.
>
> And if you send second ORF entry with IMMEDIATE field it will be pending
> completion of the first table dump just to start another one and another
> ... Getting full table in BGP is always stressful to the BGP speaker
> especially here when number of VPN routes may exceed capacity od the node.
>
> On the other hand if you DEFER your routes which caused the issue in the
> first place will still be there for some time till you send ROUTE-REFRESH
> to said RR.
>
> Draft fails to discuss this aspect and indicate when and what type of ORF
> message will be sent.
>
> Thx,
> R.
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*