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

[Robert Raszuk <[e-mail]>]

Aijun,

Cisco implemented Prefix ORF for SAFI1. We are talking about using it for
SAFI 128. So whatever any vendor is shipping today just does not matter.

> But in actual usage of the “Address Prefix ORF”, the RD is often be
ignored.

Not correct.

> *[WAJ]   *NO, The above procedures actually speak out that the RD is
passed/ignored when compared.

That is not the way I read this text.

*> [WAJ]   *No, the operator needs not intervene this process,

Then I think we are done with this proposal right here. No one will agree
to make ORF to become a transitive message. With or without policies. Note
appling any policies on IBGP is a different problem on its own.

Thank you,
R.


On Mon, Jul 20, 2020 at 8:25 AM Aijun Wang <[e-mail]>
wrote:

> Hi, Robert:
>
>
>
> The semantic encoding of “Address Prefix ORF(RFC5292)” can cover the
> proposed “RD-ORF”, but their usages is different.
>
> For the usage of “Address Prefix ORF”, please refer to
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-oubound-route-filtering.pdf
> , the device needs to configure the prefix list that used to notify the
> ORF peer. The prefix list itself does not include RD.
>
>
>
> For RD-ORF, the sender needs not do such configuration, and it can’t
> decide the RD info in advance that leads to the overwhelmed VPN table.
>
> Defining the new RD-ORF type can make the route filter policy more
> distinctly.
>
>
>
> Other detail reply are inline below.【WAJ】
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk [mailto:[e-mail]]
> *Sent:* Friday, July 17, 2020 5:43 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* Jakob Heitz (jheitz) <jheitz=[e-mail]>; Jeff
> Tantsura <[e-mail]>; Aijun Wang <[e-mail]>;
> idr@ietf. org <[e-mail]>
> *Subject:* Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> 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
>
>
>
> *[WAJ]  *In semantic encoding, it seems true.  But in actual usage of the
> “Address Prefix ORF”, the RD is often be ignored.  In RFC7543, we can
> also see the context as “ignoring the Route Distinguisher……” in  section
> 3 “Processing Rules” https://tools.ietf.org/html/rfc7543#section-3
>
>
>
> 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.
>
> *[WAJ]   *NO, The above procedures actually speak out that the RD is
> passed/ignored when 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 ?
>
> *[WAJ]   *No, the operator needs not intervene this process, but the RR
> can have its policy to send out or not the received RD-ORF messages.
>
>
>
>
>
> 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.
>
> *[WAJ]  *Even under the same administration, we can’t depend on the
> prefix limit, because the ASBR/RR has no specific VRF route table.
>
> 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.
>
> *[WAJ] *Whatever the design of RD/RT, the RD is unique to one VRF, but RT
> is not.
>
>
>
> 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.
>
> *[WAJ] * The overwhelmed PE should determines which RD or RDs leads to
> its overflow and send the specific RD-ORF message accordingly
>
>
>
> 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).
>
> *[WAJ]  *Prefix Limit mechanism can’t be used in Option B/C inter-AS
> scenarios
>
>
>
> Thx,
> R.
>