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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

Great summary. I have just one comment to your text.

> 2. The Route Distinguisher field is a fixed length of 8 octets.

I would not say that so fast. RD is a structured field per RFC4364 and when
wisely allocated it may be useful to treat it as part of a real prefix with
mask.

   The RDs are structured so that every Service Provider can administer
   its own "numbering space" (i.e., can make its own assignments of
   RDs), without conflicting with the RD assignments made by any other
   Service Provider.  An RD consists of three fields: a 2-byte type
   field, an administrator field, and an assigned number field.


Practical example:

PE_X got compromised and all VPN routes it advertises are going to
/dev/null or worse going to one customer site. So one may wish to filter
all VPN routes advertised by such PE in one shot by pushing RD/48 for type
1 RD.

Thx,
Robert.


On Mon, Feb 15, 2021 at 6:10 PM 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.
>
> 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.
>
> ---
>
> 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.
>
> 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.
>
> ---
>
> 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.)
>
> 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.
>
> 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?
>
> ---
>
> 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.
>
> 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.
>
> ---
>
> 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).
> - 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.)
>
> ---
>
> 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.
>
> 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?
>
> 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.
>
>
>
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>