Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

[Gyan Mishra <[e-mail]>]

On Thu, Aug 6, 2020 at 7:29 AM Aijun Wang <[e-mail]> wrote:

> Hi, Gyan and Robert:
>
> Maximum Prefix Limit is one method to control the routes between PE and
> CE, but we should not depend only on it.
>

   You can use maximum prefix along with an inbound filter prefix list or
as path or community match for whatever style routing control desired.

>From a PE standpoint you have not explained why using the per VRF prefix
limit to limit the size of the per VRF rib.  Please explain why that does
not solve the problem.

>
> RD-ORF can limit the influence scope of misbehavior PE as small as
> possible.
>

    I don’t think you want to use RD-ORF as that would drop all routes from
a PE and RTC does the job well only advertising RTs imported on the PE.  I
think it would be rare if ever that anyone would ever filter on RD.

>
> RT-ORF can suppress the routes from unwanted VRFs, but can’t suppress the
> overflow routes in VRF that it is interested.
>



>
> More details responses are inline below.
>
> Aijun Wang
> China Telecom
>
> On Aug 6, 2020, at 18:02, Gyan Mishra <[e-mail]> wrote:
>
> 
>
> Hi Robert
>
> I am in agreement as you stated that most service providers from my
> experience use the per VRF prefix limit to protect resources.  Problem
> solved as you said 20+ years ago.
>
> That is a general rule of thumb for any service providers to perform due
> diligence on their PE memory resource carving per VRF and set it
> appropriately based on platform and total number of VRFs to account for.
>
> Problem solved on the SP end.
>
> On the customer end, they can also use the maximum prefix peer command as
> well to prevent flood of routes in case of unwanted advertisements from
> unintentional VRF leaking by providers.
>
> Kind Regards
>
> Gyan
>
>
> On Thu, Aug 6, 2020 at 5:49 AM Robert Raszuk <[e-mail]> wrote:
>
>> Hi Gyan,
>>
>> Thank you for your comments - all very valid observations.
>>
>> Just to perhaps clarify one thing ... Problem authors are attempting to
>> address - the way I understand it - is that given resource may be suffering
>> from actually legitimate VPN routes hence to use RTC indeed a lot of
>> additional RTs would have to be applied.
>>
>> But I do not understand why authors fail to recognize that solution for
>> their problem has been invented and implemented over 20 years ago already.
>> The solution is to control on a per *ingress* VRF basis number of VPN
>> routes customer is authorized to inject into his VPN with eBGP PE-CE prefix
>> limit.
>>
>
> [WAJ] we have mentioned prefix limit solutions in the draft and analysis
> its applicability scope.
>
>
>> Most SPs offering L3VPNs use prefix limit successfully to protect their
>> shared resources for vast majority of customers and deployments. For VPN
>> customers with unpredictable amount of routing CSC model should be used
>> instead.
>>
>> By all means filtering and dropping accepted into SP network VPN route
>> should not take place.
>>
>> Thx,
>> R.
>>
>>
>>
>>
>>
>> On Thu, Aug 6, 2020 at 11:41 AM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>> Hi Aijun
>>>
>>> I agree with Robert that you cannot filter by RD or you would drop all
>>> the routes and filtering must be done by RT.  Also the issue with RT ORF
>>> filter is as Robert mentioned that you may have the same prefix with two
>>> different RTs which is common unique by RD and so the ORF would drop the
>>> prefixes.
>>>
>>
> [WAJ] Such situation can only happen at the extraVPN scenarios which
> should be designed carefully——one must keep the prefixes in these VRFs not
> overlap. But if the prefixes in these VRFs are not overlap, why do we need
> to separate them in different VRFs?
> In conclusion, this is just corner case and should be avoided in design.
>
>
>
>>> I am not sure I understand what problem you are trying to solve that is
>>> not already solved by RTC membership so that only RTs imported by the PE
>>> are what is advertised by the RR.  That is most effective way of cutting
>>> down the RT flooding that occurs in the RR to PE advertisement.  RT
>>> filtering is enabled by Default on all PEs and only if the RT is imported
>>> on the PE are the RTs accepted into the vpn rib. That works pretty well in
>>> cutting down RT advertisements by the RR.
>>>
>>> As Robert mentioned each VRF has a maximum prefix which is defined on
>>> the PE RIBs per VRF and in general on most current or even hardware within
>>> the last 10 years is a minimum 1M prefixes per VRF is pretty standard with
>>> most vendors and platforms.  The vpn rib limit is much much higher on the
>>> higher end platforms.
>>>
>>> You draft talks about inter-as issues solved with RT-ORF.  So when PE-PE
>>> inter-as option B by default all RTs are dropped due to default RT
>>> filtering and only RTs that are accepted are those RTS that are explicitly
>>> being imported on the PE ASBR.  There is an option for retain route-target
>>> all that disabled the default RT filtering so that all VPN routes can be
>>> accepted on the inter-as option B link.  However a RT filter can still be
>>> applied to the retian-route-target all so that only pertinent RTs are
>>> accepted inter domain.  That seems to work pretty well.
>>>
>>> As far as inter-as option C, the PE-PE ASBRs do not maintain the VPN
>>> RIB.  BGP LU is enabled on the inter-as link for end to end LSP by
>>> importing the loopback between ASs for the end to end LSPto be built.   The
>>> RRs between the SPs have eBGP VPN IPv4 VPN IPV6 peer with next hop
>>> unchanged so the data plane gets built between the PEs.  The RR by default
>>> does not have RT filtering enabled by default as does the PE, so is able to
>>> reflect all the vpn routes learned to all PEs within each AS.  In the
>>> inter-as scenario as well RTC works very well with the RT membership to cut
>>> down on RR to PE vpn route advertisements.
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>> On Wed, Aug 5, 2020 at 12:49 PM Aijun Wang <[e-mail]>
>>> wrote:
>>>
>>>> Hi, Robert:
>>>>
>>>> Aijun Wang
>>>> China Telecom
>>>>
>>>> On Aug 6, 2020, at 00:14, Robert Raszuk <[e-mail]> wrote:
>>>>
>>>> 
>>>>
>>>> [WAJ] The VPN routes imported in these VRFs can’t use the same RD, or
>>>>> else, the VPN prefixes in different VRFs will collision on RR.
>>>>>
>>>>
>>>> Nothing will "collide" on RRs.
>>>>
>>>> NLRI = RD+Prefix  not just the RD.
>>>>
>>>>
>>>> [WAJ] The prefix part can be overlap in different VRF. If the RD is
>>>> same, RD+Prefix will also be overlap.
>>>> We must make sure different VRF use different RD to make the VPN
>>>> prefixes unique within the domain.
>>>>
>>>>
>>>> So you may have completely different prefixes sourced by the same VRF
>>>> going to completely different VRFs on same or different PEs.
>>>>
>>>>
>>>> [WAJ] This situation is for extraVPN communication, and should be
>>>> designed carefully to avoid the address collision..
>>>> If the address space in different VRF need to be considered in such
>>>> manner, putting them in one VRF may be more straightforward.
>>>>
>>>> Kind regards,
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>>
>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>>> Spring, MD
>>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>>
>>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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