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

[Jeffrey Haas <[e-mail]>]

Aijun,

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.

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.  See the grow Working Group
for some additional discussions on prefix limits.

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

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

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

> > 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 https://tools.ietf.org/html/rfc7543.
> Is it more prune to error?

Stating the expected maxlen values would be okay.

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.


-- Jeff