[Idr] rd-orf problem clarification at remote-PE 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 remote-PE's
perspective.

---

A VPN network distributes VPN routes between PEs.  This may be done across a
variety of BGP topologies including directly attached routers using iBGP and
eBGP, leverage route reflectors and confederations.

In the absence of other mechanisms, routes are often distributed wholly
across the VPN topology.  Filtering mechanisms such as BGP policy may be
used to restrict where routes flow across such VPN networks.

RT-Constrain, RFC 4684, may be used to build subscription graphs of PEs
interested in specific route targets.

---

Problem statement:

Presume that a set of VPN routes originated to a VPN network are identified
as undesirable by one or more remote PEs.

Presume those routes are associated with a specific VPN route distinguisher.

---

Working example:

For some VPN identified by a particular route target RT-A, a VPN site
identified by VPN routes with a route distinguisher RD-1 accidentally leaks
the entire Internet routing table into the VPN.  (Currently over 3/4 million
routes.)

A remote PE that is a member of the VPN identified by RT-A receives these
routes RD-1 along with other VPN sites that it wishes to receive that are
better behaved.

---

Potential local mitigations:

1. The receiving PE may deal with the offending routes by leveraging BGP
   policy to filter the routes that have RD1 in the prefix.  This may be
   done using manually configured policy, or mechanisms like ORF.  

   However, this doesn't relieve the impact on the VPN network itself.

2. Other route attributes may be available for such filtering, depending the
   BGP VPN deployment.  An example of this may be the Route Origin Extended
   Community (RFC 4360).  This filtering may be via manually configured
   policy.  

   ORF work originally included Extended Community filtering prior to the
   use case being supplanted by RT-Constrain.  

   https://tools.ietf.org/html/draft-ietf-idr-route-filter-13, section 3.2.

   A dead IETF draft covers this behavior.
   https://tools.ietf.org/html/draft-chen-bgp-ext-community-orf-02

   Note, however, that those ORFs were not properly structured as "deny
   some, permit the rest" and would require Sequence number behavior, or
   changes in the behavior of ORF default procedures.

---

Transitive mitigations:

ORFs apply to individual BGP sessions.  

It is possible for local routers to determine to apply a per-session
mitigation mechanism.  It is possible for that per-session behavior to be
recursively applied in a BGP network.  However, this has operational
challenges:

- The originating entity for such a mitigation is not carried in the ORF
  semantics.  It becomes problematic to trace the origin of such a
  mitigation.

- The desired semantic is "do not send me this VPN route with this RD".
  Negative state is acceptable in networks, but has an operational tendency
  to become stale.  If used, it should have a short lifetime.

  (This is because the absence of the negative state for filtering can turn
  into a state explosion if the negative state is lost for some reason.)

- ORFs are potentially problamtic to implementations because they provide
  per session filtering semantics which tends to weaken peer-group
  strategies to share expesnive queueing work.

---

Issues:

1. Is there a need to signal a remote PE that it's routes are undesirable?
   If so, what does the distribution graph look like?

   (Note that this begins to resemble flood and prune mechanisms.)

2. Local mitigations are possible to reduce the impact on a receiving PE.  A
   VPN route distribution network needs to be able to deal with resource
   overload on a short term basis.  If it cannot, it has other fragility
   issues that can't be mitigated by a triggered mechanism.

   Is there any need for a signaling mechanism to attempt to mitigate this
   or should this be considered solely a matter for operator attention?
   (NOC phone, for example.)

-- Jeff