Subject: [Idr] rd-orf problem clarification at remote-PE level

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Feb 2021 13:05:49 -0500

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

---

From: Aijun Wang <[email-masked]>
Date: Tue, 16 Feb 2021 10:16:57 +0800

Hi, Jeff:
Thanks for your clarification. Let me try to respond and co-authors are welcome to complement.

Aijun Wang
China Telecom

> On Feb 16, 2021, at 01:45, Jeffrey Haas <[email-masked]> wrote:
> 
> Authors,
> 
[WAJ] Yes. But RFC4684 can only express explicitly that “What the receiver want”, not the explicit expressions that “What the receiver don’t want”

> routes RD-1 along with other VPN sites that it wishes to receive that are

[WAJ] Yes, this is the scenarios that the draft aims to solve.

>   done using manually configured policy, or mechanisms like ORF.  

[WAJ] Because we can’t know in advance which RD will let the overwhelming VPN routes, configuration policy in advance is impossible.

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

[WAJ] We think relieve the impact on the VPN network in one granular way, that is, first is the receiving PE, then the upstream RR, the the source PE. But RD-ORF message is not flooding directly out to network. Each of these devices can act as the valve to control the advertising of overwhelming VPN routes. Such flexibility can cover more scenarios, for example, if only some PEs has constrained capabilities to process the excessive VPN routes, it need not bother other PEs, the RR can restrain the VPN routes that it doesn’t want instead.

>   https://tools.ietf.org/html/draft-chen-bgp-ext-community-orf-02

[WAJ] If we can know in advance these attributes, we can. But due to the occasional occurrence, we can only expect to react quickly after it’s happening.

>   changes in the behavior of ORF default procedures.
[WAJ] The basic ORF principle is “permit some, deny the rest”, as described in https://tools.ietf.org/html/rfc5291#section-6: 
“If for a given AFI/SAFI the intersection between these two sets is non-empty, the speaker SHOULD NOT advertise to the peer any routes with that AFI/SAFI prior to receiving from the peer any ROUTE-REFRESH message carrying that AFI/SAFI, where the message could be either without any ORF entries, or with one or more ORF entry and the When-to-refresh field set to IMMEDIATE. If, on the other hand, for a given AFI/SAFI the intersection between these two sets is empty, the speaker MUST follow normal BGP procedures.”

RD-ORF mechanism follows such implicit behavior.

> recursively applied in a BGP network.

[WAJ] The ORF message is based on ROUTE-REFRESH message, it is per session behavior.

>  However, this has operational
> challenges:
> 

[WAJ] The ORF message will not be transferred automatically across different BGP sessions. It is easier to trace the sender of this message, that is, the other end of the BGP session.

>  to become stale.  If used, it should have a short lifetime.

[WAJ] Yes, after the intervention/recover of the operators once the RD-ORF message is triggered, the manual removal will be followed, as described in https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.2

>  strategies to share expesnive queueing work.
[WAJ] Yes. Unless all the peers has sent the same RD-ORF message. I think this is acceptable, considering there is seldom peer-group usage in VPN service deployment? Or if such thing happen, extracts the affected PE from the peer-group?

>   (Note that this begins to resemble flood and prune mechanisms.)
[WAJ] The RD-ORF message may or may not reach to the sourcing PE, the related intermediate node can all act as the valve to control the excess VPN routes, on behalf of its downstream BGP peers.
>   issues that can't be mitigated by a triggered mechanism.

[WAJ] RD-ORF mechanism doesn’t preclude other protections mechanism deployment . It is useful because existing mechanisms can’t reduce the occasional overwhelming of interested VPN routes.
>   (NOC phone, for example.)

[WAJ] The network should have the capabilities to react automatically, not always static configuration. After the trigger of RD-ORF, the operator will be notified. Then such mechanism give the time for operators intervention before the churn disruption.