Re: [Idr] rd-orf problem clarification at the local level

[Aijun Wang <[e-mail]>]

Hi, Jeff:
This is the reply to your comments on the local peer that initiated the RD-ORF message.

Wish these explanations can help you know RD-ORF mechanism more throughly and can refine and forward it.

Aijun Wang
China Telecom

> On Feb 16, 2021, at 01:10, Jeffrey Haas <[e-mail]> wrote:
> 
> Authors,
> 
> The IDR chairs were discussing how best to move forward the discussion about
> Working Group adoption for rd-orf.  As part of that discussion, we thought
> it would be helpful to have the discussion split to cover specific points.
> The goal is primarily to clarify the functional requirements.  As part of
> this discussion, there will be some technical observations on the proposal.
> 
> This e-mail is structured with the perceived issue, and a set of questions
> to be commented on as Issues at the end.
> 
> This e-mail focuses on the rd-orf problem statement from the receiving PE's
> perspective.  
> 
> ---
> 
> Presume we have a PE router with some number of attached VRFs.
> For this example, we have a VRF-A that uses a single route target.
> In this VRF, routes from two remote PEs with distinct route distinguishers,
> RD1 and RD2, contribute to that VRF.
> 
> ---
> 
> Presumed problem statement:
> It is possible for this VRF, and perhaps the PE itself, to be overwhelmed by
> an excess number of VPN routes.

> 
> Common implementation mitigations available today:
> 1. A VRF may implement a prefix limit that prevents an excess number of
>  routes from being redistributed from the VPN's address family into the VRF.
> 
>  However, this does not keep the PE from retaining an excess number of VPN
>  routes in its global VPN table.
[WAJ]Yes
> 
> 2. The PE may apply BGP policy to restrict the VPN routes that it will
>  accept and store.  An example of this may be policy based on BGP route
>  properties in Path Attributes such as Extended Communities.  Another
>  example may be policy based on BGP NLRI properties, such as route
>  distinguisher.  (The implementation may require configuration to cause
>  VPN routes rejected by policy to be discarded rather than stored in the
>  Adj-Ribs-In as ineligible routes.)
> 
> It is thus possible for an implementation to mitigate the impact storage
> requirements for an excess number of VPN routes with no new features.
[WAJ] As stated in previous mail, if we can know the attributes of offending routes in advance, such solution is possible. But for the scenarios that described in the draft, the overwhelming VPN routes are interested and permitted, but accept all of them can influence the capabilities for the PE to service other VRFs on it.
> 
> ---
> 
> Reducing the work for the receiving PE for unwanted routes:
> 
> It can be observed that a core benefit of RT-Constrain (RFC 4684) is that it
> permits a receiving PE to avoid receiving routes it is not interested in.
> This may also reduce the work of the sending BGP Speaker by avoiding the I/O
> overhead of the unwanted routes.
> 
> However, RT-Constrain will not help you reduce the work if you want a subset
> of the routes covered by a specific route target.

[WAJ]Yes

> 
> The desired property in rd-orf is that a BGP Speaker will exchange an
> outbound route filter that provides a list of route distinguishers that will
> be excluded from the routes sent on a session.  
> 
> Essentially, a "do not send these RD routes list".
> 
> Such an ORF can reduce the amount of work on a receiving PE, and reduce the
> storage of unwanted routes.

[WAJ] Yes

> 
> ---
> 
> Operational considerations for PE filtering using route distinguishers:
> 
> 1. A VPN route may be targeted for more than one receiving VRF.  Excluding
>  VPN routes by route distinguisher may only be done if it is operationally
>  acceptable that no VRFs on the receiving router will receiving those
>  routes, regardless of VPN membership.  
> 
>  (That is, collateral damage is a possibility that must be understood.)

[WAJ] Yes. Section https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1 in Figure 3 has described such situations, as also the example that Robert mentioned. More clear description should be clarified in the later version to achieve the determined behavior in such situations.

> 
> 2. A PE may have downstream BGP peers.  It must be operationally acceptable
>  that no downstream BGP peers receive VPN routes whose route distinguisher
>  is being filtered.
[WAJ] Yes. This is more like the behavior of RR/ASBR. More descriptions and criteria will be added for the trigger of RD-ORF message on these intermediate/proxy/leader devices.
> 
> 3. VRFs that have prefix limits may have its limit exceeded by routes from
>  multiple remote PE resources.  What is the mechanism that will permit an
>  implementation to choose what route distinguisher will be filtered,
>  presuming the collateral damage in points 1 and 2 is acceptable?
[WAJ] Currently, we consider to select the RD whose associated VPN routes occupy most part of offending VPN routes.
> 
> ---
> 
> rd-orf protocol issues:
> 
> 1. The rd-orf type specific part includes a Sequence field.  Its use in the
>  ORF filtering mechanism is unclear in the draft's text.
> 
>  It is my speculation that this comes from the Prefix ORF (RFC 5292)
>  semantics.  However, it is improperly specified, if so.  A Prefix ORF
>  requires ordering semantics in order to properly execute prefix-match
>  behavior, especially given the need for more-specific/less-specific
>  portions of the match.  In the case of an rd-orf, order is not relevant,
>  only the route-distinguisher.
[WAJ] Yes, it refers the semantic of RFC5292. But I think this field can also be useful for the list/add/remove of the filter policy, not the compared order. 
And, one correction to the previous mail for the ORF mechanism: there are permit/deny actions for the filter policy. Is it possible we also utilize this field to achieve the following effects as that you mentioned in previous mail:
1: “Permit some, deny the rest”
2:”Deny some, permit the rest”
If so, the “sequence” field can be utilized.
Anyway, we can further refine the semantic of these fields later.

> 
> 2. The Route Distinguisher field is a fixed length of 8 octets.  Using ORF
>  procedures (RFC 5291), once an ORF has been received for a given
>  AFI/SAFI, the entries of the ORF must be matched or the routes will not
>  be advertised to the remote BGP speaker.  
> 
>  This means that once there is a desire to specify a "do not send" rd-orf,
>  it becomes required that all desired RDs must be sent.  Knowing the full
>  set of possible RDs a priori is likely impossible.
> 
>  The feature thus needs a "default" entry of some sort.

[WAJ] Yes. One possible way is that adding the following RD-ORF entry in last:
“Action/permit, RD/all-zero”
If acceptable, will add such description later.

> 
> ---
> 
> Encoding rd-orf behaviors using Address-Prefix-Based ORF (RFC 5292):
> 
> Jakob Heitz, among others, has mentioned this solution.
> 
> A VPN route is made up of an RD + Prefix, with RD being a fixed 8 octet
> value from known types.
> 
> A rd-only ORF may be represented as:
> - The AFI/SAFI of the VPN address family to be filtered.
> - An appropriate Sequence number
> - A minlen of 64 bits
> - A maxlen appropriate to the AFI/SAFI of the VPN route in question (as long
> as its bit-length is <= 255).
> - Length is 64 bits
> - Prefix is the encoded route distinguisher
> 
> The default VPN Address Family ORF may be represented as:
> - The AFI/SAFI of the VPN address family to be filtered.
> - The last sequence number in the known series.
> - A minlen of 0 bits
> - A maxlen appropriate to the AFI/SAFI of the VPN route in question (as long
> as its bit-length is <= 255).

[WAJ] We should state clearly the maxlen value in every AFI/SAFI, as that done in RFC7543 https://tools.ietf.org/html/rfc7543.
Is it more prune to error?

> - Length is 0 bits
> - Prefix will not be encoded due to the Length.
> 
> The Sequence number semantics for such Prefix ORFs containing only route
> distinguishers is less important than those for Address prefixes.  The main
> requirement is that the individual members are distinctly numbered, and that
> the default entry, if present, is last.
> 
> In cases where Prefix filtering is desired for VPN routes in addition to
> route distinguisher filtering, the implementation will need to make
> appropriate adjustments to the Sequence number.
> 
> That said, aside from the popularity of ORFs in modern BGP implementations
> being low, VPN route filtering for ORFs is likely uncommon due to the need
> to known the route distinguisher a priori.  (See discussion above.)
[WAJ] Yes, it is not easy to know the RD of offending VPN routes, and it is different from the initial aim of Prefix-Based ORF, which is always planned in advance. This is the main reason that we prefer to using one distinct encoding.

> ---
> 
> Issues for discussion:
> 1. Is this analysis of the issue from the receiving PE's perspective
>  correct?  If not, please comment in the appropriate text above.
[WAJ] Basically correct. Have commented in the related parts above.
> 
> 2. What procedure would an implementation use to apply a prefix-limit to
>  trigger this filtering mechanism given that a VRF may have routes
>  contributed to by several route distinguishers?
[WAJ] Will select the RD whose associated VPN routes occupy the most part of the offending VPN routes. Will clarify this point later if necessary.
> 
> 3. Can the procedure above for using RFC 5292 address the use case?  If not,
>  please comment on the specific use case and encoding difficulty.
[WAJ] It is possible, but not very concise. We must define clearly most of used fields for every AFI/SAFI. And it is contrary in some extent the knowledge of prefix-list usage/implementation in several vendors including Cisco/Huawei and Juniper, as I have explained to Jakob in https://mailarchive.ietf.org/arch/msg/idr/sSrjOAoLZCEd2oYfJAYeryp9i4Y/
> 
> 
> 
> 
> -- Jeff