Subject: [Idr] I-D Action: draft-wang-idr-vpn-prefix-orf-01.txt

From: [email-masked]
Date: Sun, 06 Feb 2022 18:52:05 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
        Authors         : Wei Wang
                          Aijun Wang
                          Haibo Wang
                          Gyan S. Mishra
                          Shunwan Zhuang
                          Jie Dong
	Filename        : draft-wang-idr-vpn-prefix-orf-01.txt
	Pages           : 14
	Date            : 2022-02-06

Abstract:
   This draft defines a new Outbound Route Filter (ORF) type, called the
   VPN Prefix ORF.  The described VPN Prefix ORF mechanism is applicable
   when the VPN routes from different VRFs are exchanged via one shared
   BGP session(e.g. routers in a single-domain connect via Route
   Reflector).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wang-idr-vpn-prefix-orf-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Feb 2022 09:31:43 -0500

>    BGP session(e.g. routers in a single-domain connect via Route

I will repeat some comments still not addressed from prior threads:

1. This ORF defines only DENY actions.  RFC 5291 procedures, when at least
one ORF of a given ORF type is present, need a PERMIT entry in order to pass
updates for that type.

2. The sequence number does not provide semantic meaning in the ORF itself
for filtering purposes.  The authors have previously explained it is useful
for troubleshooting.  However, since ORF REMOVE procedures require that the
entire ORF be passed for removal, this additional piece of data could result
in bugs where a given removal for a given RD is not done because of a
mismatch of the unused sequence number.  In such cases, REMOVE-ALL followed
by re-adding would be necessary.  I would recommend that this field be
removed from the proposal.

-- Jeff

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 11 Feb 2022 10:52:07 +0800

Hi, Jeffrey:

As described in https://datatracker.ietf.org/doc/html/rfc5291#section-6, the
PERMIT ALL effect should be achieved as the following methods:
"If the speaker receives from the peer a ROUTE-REFRESH message without
   any ORF entries, then the speaker sends to the peer all routes from
   the Adj-RIB-Out associated with the peer whose AFI/SAFI is the same
   as what is carried in the message and taking into account the ORFs
   (if any) previously received from the peer."
Then when the "Length of ORF entries" field in the "ROUTE-REFRESH" message
is set to zero, it signals the peers "PERMIT ALL", right?
If so, we can also add such description to the implementation part, together
with the Robert's suggestions.

For the "Sequence" field in the type-specific part, its meaning is not only
for troubleshooting, it should be also the matching order of the filer, same
as the usage in "Address Prefix ORF" (RFC5292) and "CP-ORF"(RFC7543)
To REMOVE one specific ORF entry, the "Sequence" number need also be
matched. Or else, the action will not be taken, as that described in
RFC5291:
" If the Action component of an ORF entry is REMOVE, but the ORF
   previously received does not contain the specified entry, the ORF
   entry in the message is ignored."

REMOVE-ALL followed by re-adding seems not efficient as the above determined
REMOVE action?

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Thursday, February 10, 2022 10:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] I-D Action: draft-wang-idr-vpn-prefix-orf-01.txt

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 11 Feb 2022 07:23:05 -0500

Aijun,

> is set to zero, it signals the peers "PERMIT ALL", right?

It does not.

The way to think about this is the Length of ORF entries is simply the
policy elements that are following.  Each individual elements is to be added
or removed from the ORF for that AFI/SAFI.

You can use zero length to signal no additional filters to be added.  But
you could also do a when to refresh of immediate when the message contains
the last set of ORFs to be processed.

The relevant section is this:
:   If the When-to-refresh indicates IMMEDIATE, then after processing all
:   the ORF entries carried in the message the speaker re-advertises to
:   the peer routes from the Adj-RIB-Out associated with the peer that
:   have the same AFI/SAFI as what is carried in the message, and taking
:   into account all the ORF entries for that AFI/SAFI received from the
:   peer. 

So, if there are no ORFs for that AFI/SAFI, it doesn't have impact.

If there's at least one ORF, you follow the list.

Your draft specifies only DENY semantics.  There's no implicit accept ORF.
The base procedures for ORF don't have an implicit PERMIT-ALL if not
otherwise denied.

>    entry in the message is ignored."

The desired semantics of your filters are "reject any that match these
properties".  Why is order important in your filter?

This might be more relevant once you decide how you want to address the
permit case.

In the case of prefix ORFs, it's an ordered prefix list similar to a
firewall, rather than a simple longest-match prefix list policy element.
(This is one of the properties that stalled vendor interest.  It was very
friendly toward older Cisco filtering syntax, but less so to other vendors.
:-)

A vendor wanting to implement your filter would want to take the RD entries
and simply put them into a fast lookup tree, e.g. PATRICIA.  Forcing
ordering means you either do suboptimal lookup mechanisms such as linked
list or have a much more complicated longest match tree with walk up for
ordering semantic.  You don't seem to need ordering, so don't complicate the
implementation. 

> REMOVE-ALL followed by re-adding seems not efficient as the above determined

Remove can remove entries without a sequence number.  Consider it similar to
a withdraw for an NLRI.

-- Jeff

---

From: Aijun Wang <[email-masked]>
Date: Sat, 12 Feb 2022 11:10:56 +0800

Hi, Jeffrey:
To simplify the implementation, can we make a rule for the newly defined ORF type, that the default action is “permit ALL”? 
Then the sequence field need not exist, and what you mentioned “REMOVE” action maybe more easily achieved.
All the explicit entries in such kind of ORF type is “DENY” rule.

Aijun Wang
China Telecom

> 在 2022年2月11日，20:23，Jeffrey Haas <[email-masked]> 写道：
> 
> PATRICIA