Subject: [Idr] RFC 4684 pedantry - routes with no Route Target

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 08:47:53 -0400

IDR,

RFC 4684 (Constrained Route Target Distribution) is obviously a useful tool.
At work, we've run into an interesting case and I thought I'd share some of
the internal debate on it.

In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the following
documentation in section 4.4:

:   When a PE distributes this NLRI via BGP, it may include a Route
:   Target (RT) Extended Communities attribute.  This RT must be an
:   "Import RT" [RFC4364] of each VRF in the MD.  The ordinary BGP
:   distribution procedures used by [RFC4364] will then ensure that each
:   PE learns the MDT-SAFI "address" of each of the other PEs in the MD,
:   and that the learned MDT-SAFI addresses get associated with the right
:   VRFs.

RFC 4684's procedure says in section 6:
:   A VPN NLRI route should be advertised to a peer that participates in
:   the exchange of Route Target membership information if that peer has
:   advertised either the default Route Target membership NLRI or a Route
:   Target membership NLRI containing any of the targets contained in the
:   extended communities attribute of the VPN route in question.

Quite frankly, we have a bug in that MDT's are not getting propagated when
RT-C is in use because we're treating it as a "VPN NLRI".  Simple fix, but
one that leaves me wondering if the issue is more general - and perhaps
worthy of an errata for RFC 4684.

For the MDT case, one can make the argument that since it may be distributed
without RTs, it's only a "VPN NLRI" if it contains RTs.

The broader question I'd put to the working group is whether any NLRI not
having RTs isn't really a "VPN NLRI" for purposes of RT-C filtering.  This
really leaves two simple schools of thought:
1. No RT, no RT-C filtering.
2. MDT SAFI is an odd-ball case, just deal with that.  (And perhaps warn in
future BGP documents that may use RT-C about how to deal with no RTs when
they're optional.)

-- Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 21 May 2014 15:07:32 +0000

I am for 1. No RT, no RT-C filtering.
Moreover, for ANY address family (including RT-C) if an UPDATE includes an RT, then RT-C filter it. No special exceptions if an RT-C UPDATE contains the same RT in the NLRI and the attribute field.

--
Jakob Heitz.

> On May 21, 2014, at 5:48 AM, "Jeffrey Haas" <[email-masked]> wrote:
> 
> IDR,
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Eric Rosen <[email-masked]>
Date: Wed, 21 May 2014 11:21:44 -0400

Jeff> In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the
Jeff> following documentation in section 4.4:

The next paragraph though makes it clear (well, sort of) that the MDT-SAFI
routes without RTs need to be distributed to all the PEs, and filtered as
necessary by the PEs to which they are distributed.  
   
Jeff> RFC 4684's procedure says in section 6:

Jeff> Quite frankly, we have a bug in that MDT's are not getting propagated
Jeff> when RT-C is in use because we're treating it as a "VPN NLRI".

Yes, one might conclude that whoever decided to omit the RTs from MDT-SAFIs
wasn't much concerned about the use of RT-C (or any other RT-based filtering
mechanisms) to constrain the distribution of routes to or from intermediate
nodes.

Jeff> The broader question I'd put to the working group is whether any NLRI
Jeff> not  having RTs isn't really a "VPN NLRI" for purposes of RT-C
Jeff> filtering

I don't think RFC4684 really intends to restrict its applicability to "VPN
routes".  It does say in section 1: "This mechanism is applicable to any BGP
NLRI that controls the distribution of routing information by using Route
Targets".  The problem arises because, on some NLRIs, the use of RTs is
optional.  What you're suggesting is that RT-C should never filter out
routes that don't have any RTs.  That does seem right.

You may want to look at draft-zzhang-l3vpn-mvpn-global-table-mcast-02.txt,
especially section 2.2 ("Route Targets").  In that draft, there are routes
of the MCAST-VPN SAFI that may (optionally) carry RTs, and the intention is
that it be possible to use RT-C to constrain the distribution of those
routes, if (and only if) the routes carry RTs.  However, those routes cannot
really be said to be VPN routes, as they are used for controlling multicasts
that do not occur in a VPN context.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 11:52:25 -0400

On Wed, May 21, 2014 at 11:21:44AM -0400, Eric Rosen wrote:
> Targets".

(And Jakob also raised the same point.)

It should be noted that we leveraged the same thing for the
draft-ietf-idr-mdcs proposal. :-)

> The problem arises because, on some NLRIs, the use of RTs is

I think that's 3 people that are in agreement.  I'd like to leave the
discussion open for a little bit to get additional consensus in the WG.

Chairs, presuming that we do end up with that sort of behavioral consensus
about no RT's, is an errata against RFC 4684 sufficient or would you want to
see something more?

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 18:20:58 +0200

Hi Eric,

> routes that don't have any RTs.  That does seem right.

Well is it really ... ?

Remember that RFC 4684 enforces for any SAFI it is enabled under no
route exchange happens at all till intersecting RTs are received over
RTC SAFI.

That means that the spec is 180 degrees opposite to your above claim
that routes with no RTs should be always exchanged.

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 18:33:24 +0200

In the situations where protocol SAFI contains a mix (tagged and not
tagged NLRIs with RTs) I would rather propose to amend the rfc to
exchange default RT + specific RTs. That would potentially allow for
reception of NLRIs with no RT attached + filtering of those against
more specific RTs received which do carry RT ext community.

Thoughts ?

r.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 12:36:21 -0400

Robert,

> that routes with no RTs should be always exchanged.

While a complicating factor certainly, we'd still end up sending along those
routes after either end-of-rib for RT-C or the timeout.  (Presuming the
implementation follows the SHOULD.)

So, while it causes potential delay to the subset of the routes carrying no
RT, presumably they're in the same family because some of the routes will
have an RT and want to benefit from the feature.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 12:37:42 -0400

> more specific RTs received which do carry RT ext community.

Default RT-C effectively negates the usefulness of the feature.  I wouldn't
recommend this.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 18:38:49 +0200

> implementation follows the SHOULD.)

After timeout yes, but not after valid set of RTC RT NLRIs followed by
EOR. .. I would not expect to see those in the latter case.

r.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 18:40:53 +0200

It all depends how you implement your filters :)

r.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 18:46:03 +0200

Assume I do have a valid SR application to filter tiny subset of
Internet table. For this I can mark such tiny subset of routes with
RTs, enable RTC and activate RT filtering on IPv4 session.

Sending full table there where I need only few routes would kill the
optimization completely.

Btw .. how do you handle the same problem with ORF ?

r.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 12:46:29 -0400

> EOR. .. I would not expect to see those in the latter case.

I believe that's the point of contention.  Should we be applying filters
when there's nothing to match on?

To echo a point Yakov raised in a side chat, what this would mean
protocol-wise would be a NULL RT-C entry.  This is distinct from a default
which is a "match all".

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 18:48:46 +0200

Well I like Yakov's suggestion.

Default was just an example - however his proposal behavior matches
(at least mine) expectation :)

So perhaps we should amend RFC4684 with NULL RT entry and encode it
somehow different then DEFAULT RT entry.

r.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 12:50:01 -0400

> It all depends how you implement your filters :)

I'm not clear how this could be the case, even at a protocol abstraction
level.  Since RT-C entries are effectively longest match on RT (although I
know there's a push to change that behavior as part of the IPv6 work), for
any set of RT-Cs including default, any route containing an RT will match
default.  You're thus not constraining much at all. 

Modulo policy limiting the distribution of default in your network, of
course.  But I'm talking about on a single router.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 18:55:16 +0200

I meant that you do not execute the match of the default entry for
routes which contain RT AND RTC send anything more specific then
default RT.

But NULL RT idea is much more elegant and does not require any of the
above twicks.

R.

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 29 May 2014 14:20:50 -0400

Jeff,

> about no RT's, is an errata against RFC 4684 sufficient or would you want to

http://www.ietf.org/iesg/statement/errata-processing.html has some guidance for how to handle proposed errata. I think it’s hard to argue that this oversight in 4684 (that it’s silent on the subject of routes that have no RTs) is an outright error — it’s an oversight. To make matters worse, the most obvious parsing of 4684 (to me, anyway) is that you should fail closed, not open as you propose. So the only item I see in the guidelines that might apply is:

	• Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update.

That gives us the options of “hold for document update” or “rejected”. Neither one of those is what we want in order to actually update 4684, which is “verified”. So I think that, irrespective of what I want, we probably have to formally update 4684. For that matter, I’m not convinced that it’s obvious that there’s a real WG consensus on the proposed behavior. 

So, sorry, I do think it needs a draft of its own.

—John

---

From: Eric Rosen <[email-masked]>
Date: Fri, 30 May 2014 09:04:58 -0400

> For that matter, I'm not convinced that it's obvious that there's a real
> WG consensus on the proposed behavior.

I think everyone agrees that it should be possible to enable RTC on a
particular AFI/SAFI, while allowing "RT-less routes" (routes with no RTs) of
that AFI/SAFI to be distributed.

I don't know whether there is consensus on the following question:  should
it be possible to enable RTC on a particular AFI/SAFI, while causing
"RT-less" routes to be filtered?

If we want to say that RT-less routes should always be distributed, no new
protocol constructs are needed, just a "clarification" of the existing
text.  I like this approach, but perhaps it won't achieve consensus.

If we want to use RTC to declare dynamically whether RT-less routes are to
be distributed or whether they are to be filtered, then we need the
"null-RT" construct.  We would then have to decide whether (assuming RTC is
enabled for a given AFI/SAFI):

1. RT-less routes get distributed unless we advertise null-RT,

2. RT-less routes get distributed only if we advertise null-RT.

I like 1. myself (if we even need to have an option for filtering RT-less
routes). 

If we need the null-RT construct, we need to specify how to code it.  Now we
get into a backwards compatibility issue.  Perhaps it can be coded as a
96-bit NLRI, where the RT part looks like a transitive IPv4-address-specific
route target with all zero in the global and local administrator fields.
The hope is that this looks like a real RT to existing implementations, but
won't actually match any RT.  So it would be a no-op to existing
implementations, and newer implementations would recognize it as a null-RT.
(An alternative would be to code null-RT as, say, an eight-bit prefix of all
zeroes, and to use a Capability to make sure that your peer can process it.)

Comments?

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 May 2014 16:29:03 +0200

Hi Eric,

I think the crux of your question and this topic sits really in
AFI/SAFI specifics.

Let's consider SAFI 128 - how good does it serve to inject to the RRs
in the network say 1M of VPN routes without any RT attached to it -
which perhaps by some bug or other action got into VPNv4 BGP table on
any of the PEs.

Take also another example of someone using RTC for SAFI 1. What good
does the RTC there serves to receive all routes - including those with
no RT attached when need is to only get just few procent on them.
Would we need to fall back to prefix ORF there ?

I am not negating that on the other side for MDT SAFI it may very well
turn useful.

So I would vote for defining NULL-RT while the default should be not
to send any routes without intersecting RT attached or we could
perhaps allow the default to be SAFI specific.

As to the encoding I would see that to be complaint with current
RFC4684 (96 bit field would not be) yet backwords compatible we can
use all Fs in all 8 octets of the RT field. It will be backwards
compatible as per RFC4360 it will never be a legal RT value (T flag is
0 for example :)

Regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 May 2014 17:16:02 +0200

Just typo fix of the last paragraph ...

s/96 bit field would not be/96 bit field would be/

So it should read:

As to the encoding I would see that to be complaint with current
RFC4684 (96 bit field would be) yet backwords compatible we can
use all Fs in all 8 octets of the RT field. It will be backwards
compatible as per RFC4360 it will never be a legal RT value (T flag is
0 for example :)

Sorry,
r.