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

Aijun Wang <> Thu, 25 February 2021 03:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A24783A0D76; Wed, 24 Feb 2021 19:09:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sX_5wwcIQqg8; Wed, 24 Feb 2021 19:09:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39B8C3A0D7A; Wed, 24 Feb 2021 19:09:17 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown []) by (Hmail) with ESMTPA id 04C431C015E; Thu, 25 Feb 2021 11:09:14 +0800 (CST)
From: "Aijun Wang" <>
To: "'Jeffrey Haas'" <>, "'Aijun Wang'" <>
Cc: <>, <>
References: <> <>
In-Reply-To: <>
Date: Thu, 25 Feb 2021 11:09:13 +0800
Message-ID: <009401d70b23$98ae7550$ca0b5ff0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGYml9sUniEXPJxI92qcLdn9XeMugFQ/VSIqtp7sRA=
Content-Language: zh-cn
X-HM-Tid: 0a77d729780ad993kuws04c431c015e
Archived-At: <>
Subject: Re: [Idr] rd-orf problem clarification at the local level
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Feb 2021 03:09:22 -0000

Hi, Jeffrey:

-----Original Message-----
From: <> On Behalf Of Jeffrey Haas
Sent: Thursday, February 25, 2021 5:00 AM
To: Aijun Wang <>
Subject: Re: [Idr] rd-orf problem clarification at the local level


On Tue, Feb 16, 2021 at 01:06:20PM +0800, Aijun Wang wrote:
> > 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.

That may be operationally acceptable for your deployment.  For others, that may not work.  

As an example, consider RD1 contributes a large number of prefixes that are expected.  RD2, which is normally a small number of prefixes, causes the table to exceed its limit.  RD1 routes would be removed even though they are desirable ones.
[WAJ] I think such situation is acceptable. We should understand first that the VPN routes associated with RD1 and RD2 are all legitimate, that is to say, all are desirable one from the beginning of deployment.
Once the RD-ORF is triggered, the operator should intervene to find the real reason for it.  It may be the PE should be upgraded, or there are too many VPN routes with RD1. Anyway, remove the VPN routes with RD2 is not reasonable. 

I do not suggest a single correct behavior.  However, your operational considerations should discuss how prioritization may need to vary depending on the operator desires and what this might look like.  One example is this may turn into a "per-RD prefix limit" feature.
[WAJ] Set the "per-RD prefix limit" to one common value is acceptable(that is to say, such threshold is RD-independent) and can be used to trigger the RD-ORF message in future. But set different value for different RD is not possible, because normally the receive PE don't know the RD that assigned by the remote peer in advance.
  See the grow Working Group for some additional discussions on prefix limits.
[WAJ] Will try to follow the related discussions.

> > 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. 

If there are no prefixes associated with the RD (it's the entire set of bytes), then the Sequence field isn't helpful.  It actually makes it ambiguous.

For example, Sequence = 1, RD = A - if you withdraw Sequence = 2 RD = A, it wouldn't match.  All that is needed to add or withdraw without some sort of prefix length is the RD.

That said, prefix length for purposes of wildcarding would work.  For example, "permit by default".
[WAJ] Will reconsider the related design to accomplish the effect of "permit by default"

> 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.

This is an important protocol detail, particularly how you say "match all RD, permit" for the wildcard rule.
[WAJ] Yes

> > 
> > 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.

All zero may be an acceptable encoding
[WAJ] Yes, will consider this 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
> Is it more prune to error?

Stating the expected maxlen values would be okay.
[WAJ] My consideration is that we don't touch the prefix-ORF to accomplish the RD-ORF effects. Because the prefix part(considering the current implement status and the normal understandings of its semantic) and the RD part will not be changed in different address families.
Focus on the standardization for the fix parts of the address can keep the RFC stable, or else, we must update it once there are new address families emerged. 

The decision would be that if the existing Prefix-ORF is acceptable for your use case, as we have discussed for this point, then perhaps there is no new ORF work to be done. You would be documenting a use case for the existing feature.
[WAJ] Except the above reason, and as discussed with Robert previously, we are considering to add the RT information together with current RD-ORF semantics. Then reusing the existing Prefix-ORF is not the right way to forward.

-- Jeff

Idr mailing list