Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

[Robert Raszuk <[e-mail]>]

Hi Aijun,

>From our POV, the user of the address-prefix ORF will pay more attention to
> the prefix itself
>

First the "user" is the implementation ... hope you are not expecting real
operator to inject such ORF entries when "overflow" happens.

Let's also observe that In L3VPNs_PREFIX = RD + IPv4_PREFIX

For example, we can refer to https://tools.ietf.org/html/rfc7543 (Covering
> Prefixes Outbound Route Filter for BGP-4), the minLen, maxLen and host
> address encoding do not include the RD(when comparing the received route,
> the receiver needs to add 64 to minLen/maxLen)
>

Incorrect.

The RFC says:

   o  the route prefix length is greater than or equal to the CP-ORF
      Minlen plus 64 (i.e., the length of a VPN Route Distinguisher);


  Note: ==equal== So that means that at least RD must be compared.


Actually, the RD-ORF message will be regenerated between every BGP session,
not propagate directly back to the upstream, as that done in BGP Update
messages.

Then, every regeneration point(RR/ASBR) can control whether or not send the
newly generated RD-ORF to the upstream.  In scenarios that when not all of
PEs are overwhelmed by routes from this specified VPN, the RR/ASBR can
constraint the sending of the RD-ORF policy to the source.

"Regeneration" follows propagation. This is exactly why we defined RTC so
all loop free properties are still met. ORF is point to point.

Or do you mean that when RR receives the RD-ORF from sending PE it will not
propagate till an operator pushes a new configuration to propagate this
further. If so have you even considered timing of those events ?


The edge between CE and PE is one control point to restrict the prefixes
number, but we can’t rely solely on it, especially in the Option-B/Option-C
interconnection scenario.

Using RD-ORF mechanism, we can prevent the overwhelmed VPN prefixes in one
AS to influence PEs in another AS, and also the PEs within same AS(when
they exchange routes via RR)

The reason for the occurrences of overwhelmed VPN prefixes may be
misconfiguration on one PE, or being attacked from the outside of network,
or other unforeseeable events.



ORF means installing additional route filter outbound from a BGP speaker as
instructed by the peer.


I do not see how any Option-B or worse Option-C peer will allow different
AS to push some VPN prefix filter on his infrastructure. Unless both are
under the same administration - but then you can use prefix limit.


Again I do not support your assertion that RD is more granular then RT for
this purpose. It all depends how given operator designed the RT and/or RD
allocations.


As mentioned for a given VPN importing VRF copies prefixes and *ovverrides*
incoming RD with local one. So just think what happens if that specific VRF
"overflows" but there is many sources of original pre-import routes all
with different RDs.


If anything in this space I would rather see us perhaps trying to automate
prefix limit per RT (in this case it would be export RTs carried with the
routes not import RTs).


Thx,
R.