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

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Jun 2014 16:40:17 -0400

On Wed, May 21, 2014 at 06:46:03PM +0200, Robert Raszuk wrote:
> 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.

After letting this thought get some of my background thinking time during a
very nice vacation, I think you've identified a key argument.  When the
expectation is you want to apply RT-C to an AF that isn't normally VPN-like
(and we've identified we may want to generally do this), the routes may not
be normally tagged with RTs.

This suggests the behavior we want may be:
- Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing.
  JUNOS, e.g., filters VPN families by default.
- Provide for exceptions to the rule and document them.

That second point covers the MDT scenario.  It also suggests that IDR should
probably make sure the other WGs using BGP as a transport for their VPNs or
otherwise using RTs should be reminded that RT-C exists and their extensions
had best document their interaction with it if they inconsistently RT tag
their routes.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Jun 2014 22:51:50 +0200

Hi Jeff,

Naturally I fully agree with your conclusion ;-)

> - Provide for exceptions to the rule and document them.

I think all implementations of RTC I looked at do both of those
already (modulo your definition of "RT-C processing").

You are nowhere mentioning the need for NULL-RT encoding which sort of
leads me to guess that you want this to be a static config on both
ends per peer/per safi. Is this what the hidden context is ?

If so I would be actually fine with that too. Just let's spell it out
for clarity.

After all you provision SAFI once for all so extra setup twick for MDT
safi as example should be peanut.

Best,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Jun 2014 17:02:24 -0400

Robert,

> already (modulo your definition of "RT-C processing").

That second point, for MDT, is what prompted the whole conversation in the
first place.  JUNOS and another vendor weren't interoperating when RT-C was
enabled.  If we read the RT-C spec as "no RT, then route is filtered out",
the other vendor is non-conformant.  The fact that the MDT spec said that
RTs are optional is mostly the fact that the feature wasn't reconciled
against RT-C's filtering behavior.

> If so I would be actually fine with that too. Just let's spell it out

That's what I'm suggesting.  The idea of a NULL-RT-C isn't something I'm a
fan of.

If the above gains consensus, I'm not sure there's anything to be put in an
I-D.  If there is, it's "RT-C procedures may be disabled on an AFI/SAFI that
is provisioned to use it on a per-route basis when that route does not
contain a RT.  This is currently recommended for ..."

Personally, I'm at my quota for small janitorial RFCs for the moment.
Maybe once one of my current ones hit RFC I'll volunteer. :-)

-- Jeff

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 16 Jun 2014 03:51:33 +0000

Hi Jeff, 

>   JUNOS, e.g., filters VPN families by default.

Agree that this way we can solve some problem without modifying the RTC protocol, a.k.a backward compatibility is maintained.

> had best document their interaction with it if they inconsistently RT tag their
> routes.

Fully agree that for different VPNs which may use RTC, the possible interaction and extensions should be documented somewhere. Then RFC 4684 may need to be updated by many newly defined VPN specifications.

This reminds me of the MP-BGP (RFC 4760), which keeps stable while can support lots of new VPNs. I'm thinking whether we should make RTC a scalable and stable mechanism in a similar way.

Thoughts?

Best regards,
Jie