Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

On Fri, Aug 28, 2020 at 8:47 AM Robert Raszuk <robert@raszuk.net> wrote:

> Hi Aijun,
>
>
>> [WAJ] Inter-AS B/C or AB. Not Option A
>>
>> RTC can be deployed in all inter-as options.
>
> All you need is to add one RT per VRF and you are done.
>>
>> [WAJ] Which RT will you add? Can you forecast which RT will cause the
>> overwhelming VPN routes?
>>
>
> You would add RT numerically identical to your local VRF RD. You will not
> use it for import. You will *only* use it to signal which src VRF is
> "overwhelming" your network and such routes will be filtered at src.
> Exactly as you are asking.
>

    Gyan> Understood so similar additive RT used traditionally for bleeding
routes or hub/spoke style have the VRFs on each PE have a 2nd RT defined on
each VRF defined on each VRF on each PE.  So that 2nd RT would represent
all routes in the VRF, same as the first RT, so it would filter at RT level
all routes within a VRF and not source PE originating the routes as would
happen with RD-ORF at RD source PE originating the flood.  Another idea
would be difficult but you could match on a special standard flood
communities created or match on prefixes for the 2nd RT so the 2nd RT now
represents all routes being sourced from the PE that is causing the flood.
This would be a very manual process but once you have the 2nd RT defined to
represent the locally originated routes from each PE you can now apply and
RT import policy on any PE to block the trashing routes.  Imagine if you
have 1000s of VPNs defined on each PE.  Quite complicated.

>
> [WAJ] Welcome your other comments. Please do not loop around RTC(we have
>> explained several times, also in updated draft. Please see
>> https://tools.ietf.org/html/draft-wang-idr-rd-orf-03#section-1
>>
>
>    1) Route Target Constraint
>
>
>
>    RTC can only filter the VPN routes from the uninterested VRFs, if the
>
>    "trashing routes" come from the interested VRF, filter on RTs will
>
>    erase all prefixes from this VRF.
>
>
> Your explanation is incorrect or at best incomplete. You can use RT as any
> other community to color the routes.  Export RT and import RT are
> completely independent functionality.
>
> To reiterate: you export your routes with one additional RT (equal to
> local RD). You import routes as today - no change. So when some imported
> routes are detected to be "overwhelming" you just take the new RT and
> signal it with RTC to stop src (or RR) sending those to you in EXACTLY same
> way you would use RD for such filtering.
>

   Gyan> I think what Aijun was trying to say which needed rewriting of the
verbiage is that by default all all PEs have “RT Filtering” enabled by
default so if you don’t have an explicit import on an RT the PE drops the
vpn prefixes coming from the RR.  So RTC is quite powerful in that it can
be more efficient and optimized as far as RT distribution graph with the RT
membership ORF rib-out on PE-RR intra-as instead of advertising all what
Aijun called “uninteresting” RTs in the reverse direction the RR only
advertises the RTs being imported on the PEs.  Intra-AS RTC cuts down on
default all RT advertisements and it most advantageous in sparse RT
distribution graph.  RTC can also be very handy inter-as as well as we have
agreed which allows the inter as options B and AB and even some cases C to
be more plausible between administrative domains using the RTC membership
to cut down on advertisement of RTs not being imported between domains.  So
with this draft RD-ORF provides a layer of granularity at the RD origin PE
advertising the flood of prefixes layer and can be deployed both inter and
intra domain.  This makes the inter-as option B and C more viable between
administrative domains.  Option AB does have resolves the Option A BGP
control plane scalability issue but with the added separation of data plane
isolation in this AB hybrid model it requires having an interface or sub
interface per VRF so that does become challenging if you have 1000s of
VPNs.  So this draft along with use of RTC and all other controls in place
makes Option B and C viable as now you have that origin PE RD offender
granularity to mitigate floods.

>
> It is so basic ...
>
> Cheers,
> R.
>
>
> _______________________________________________
>
> Idr mailing list
>
> Idr@ietf.org
>
> https://www.ietf.org/mailman/listinfo/idr
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD