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

[Robert Raszuk <[e-mail]>]

Aijun,

*[WAJ] Route Import is based on RTs, but different VRFs on one PE will use
> different RDs(and also different import RTs). Then filter based on RD will
> not influence the route import in another VRF, especially within the same
> PE.*
>

That is incorrect.

When you filter VPNv4 routes based on the RD you are suppressing this route
say on remote PE or RR such that it will never arrive on the PE.

And please kindly observe that VPNv4 routes carry a lot of RTs attached. So
one VRF may import this route based on the RT1 and the other may import the
same route based on the presence of RT2.

That means that healthy VRF may no longer be able to import this route when
you suppress it upstream in spite of the fact that there is no problem with
overflow on a given VRF.

Your scheme could work if we would assume no extranets nor more then one RT
per VPNv4 route. But this is not the case in the specification nor in any
deployment I have seen or run.


For me this is showstopper - and pretty fatal one to use RD for filtering.
> We do import based on RTs and filtering should also be done based on the
> RTs.
>
> *[WAJ] RT can’t be uniquely to identify one specified VPN.*
>

It sure can. Just add one more RT to identify the VPN on export. You may
not even ever import that RT anywhere. It would be used just as a VPN-ID in
your network.


> My other serious concern is that end customer will in no one be notified
> about such RD-ORF filtering ... - that is frankly not acceptable to me or
> to any L3VPN or L2VPN customer. As comparison when you use prefix limit on
> the PE-CE customer's session goes down hence customer is alerted about the
> problem.
>
> See worst "solutions" are those which may cause silent failures. We should
> avoid those at all cost.
>
> *[WAJ] The RD-ORF message is initiated from the overflow PE.  The RR or
> the source of VPN overflow act based on the instruction from the applier.
> Then this is not silent failures.*
>

There is no such a thing like an overflow PE. PE has different RIBs usually
one per VRF. So ultimately the overflow is coming from a VRF. And as we
proven that is not possible to avoid based on the RD filtering without
affecting other VRFs.

It is a silent failure for customers as customers never see the RD-ORF.

I would be willing to state that it may be better to fail such overflown PE
other then trying to recover and keep it running on the clif by shaving of
VPN routes arrving to it. Either such PE needs replacement or operator
running such PE needs to update his resume.


> *[WAJ] RD-ORF just want to keep the disaster as small as possible, based
> on the parachutes **J*
>

We are here to avoid silent disasters. Or when it happens make a big enough
boom.

Thx,
R.