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

[Jeffrey Haas <[e-mail]>]

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