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

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

Hi Eric, 

Some of my thoughts about this discussion:

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

In my understanding, this implies two things: 

 1) RTC could be enabled on a particular AFI/SAFI;
 2) RTC processing for different AFI/SAFIs could be different;

While currently RTC is a global capability, which cannot be enabled on a particular AFI/SAFI only, either cannot behave differently for different AFI/SAFIs. So can I infer that you prefer to make RTC a AFI/SAFI specific capability?

Best regards,
Jie

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 16 Jun 2014 10:28:28 +0200

Jie,

>  1) RTC could be enabled on a particular AFI/SAFI;

​Yes.​

>  2) RTC processing for different AFI/SAFIs could be different;

​No.​

> While currently RTC is a global capability, which cannot be enabled on a
> particular AFI/SAFI only,

​Of course we can - why not ? To send RTs and to process them requires a
command on a per AF basis. ​

> either cannot behave differently for different AFI/SAFIs.

​That was never subject of this discussion. It's completely separate change
which does require changes to base spec.​

So can I infer that you prefer to make RTC a AFI/SAFI specific capability?

​That was also never part of this topic.

I would recommend to separate the discussion into specifying ​the default
behavior for routes with no RTs while separately discuss changes to base
RFC to make it per AFI/SAFI (provided there is community support for such
major rewrite).

Best,
R.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 17 Jun 2014 02:14:51 +0000

Hi Robert,

Thanks for your comments, please see my replies inline:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, June 16, 2014 4:28 PM
To: Dongjie (Jimmy)
Cc: [email-masked]; John G. Scudder; [email-masked]
Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target

Jie,

​Yes.​

​No.​

#Jie: The RTC processing for the MDT SAFI is not the same as for other VPN AFI/SAFIs, is my understanding correct?

While currently RTC is a global capability, which cannot be enabled on a particular AFI/SAFI only,

​Of course we can - why not ? To send RTs and to process them requires a command on a per AF basis. ​

#Jie: I guess you mean using some per-AFI/SAFI knob as mentioned in Jeff’s mail:

- Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing.

While this could control the local RTC processing, the point is with current RTC capability negotiation the BGP peer only knows that RTC is enabled on this session, and has no idea which AFI/SAFI on its peer is allowed by the local knob to process RTC. If on two peering speakers the knobs are enabled inconsistently, this cannot be found through BGP capability advertisement. Since RTC can work correctly only if the knob is enabled consistently in the network, it may be helpful to advertise the RTC capability of specific AFI/SAFIs.

​That was never subject of this discussion. It's completely separate change which does require changes to base spec.​

#Jie: the MDT SAFI requires different RTC processing, and it warns us that some other address families may have similar requirement in future. This may be achieved either by AF specific update documents, or by some update to the base spec.

I would recommend to separate the discussion into specifying ​the default behavior for routes with no RTs while separately discuss changes to base RFC to make it per AFI/SAFI (provided there is community support for such major rewrite).

#Jie: The default behavior for routes with no RTs may be different for different AFI/SAFIs, that’s why I brings the AFI/SAFI specific discussion here.

I’m OK with continuing this per AFI/SAFI discussion separately, and I also prefer not to make major changes to base RTC if possible.

Best regards,
Jie

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jun 2014 08:55:00 +0200

Hi Jie,

#Jie: The RTC processing for the MDT SAFI is not the same as for other VPN
> AFI/SAFIs, is my understanding correct?
>

​Not sure what you call processing.

The current RTC model is that you advertise interesting RTs as a global
property of the peer. It's not even per session as far as set of advertised
RTs.

That means that given RT value should be used for specific address family
or if there is congruence for more the one AF.

That also means that in order to apply different filtering rules on a per
specific SAFI basis set of RTs used by that SAFI must be unique.

Of course one can debate if this model is best or not but if you think
about VPN focus as major application the VPN topologies do not different
that much on a per AFI/SAFI basis for a given customer.

Moreover I do not think we are anywhere near starvation in the space of 6
or 18 octet RTs.

As to your comment of using BGP capability to verify configuration
correctness on both ends well while the idea is great there are much more
knobs and twicks in BGP which would benefit from the same. Do we want to
load all of them to capabilities ? I am under impression that we should
keep capabilities only to critical session related information.

​Moreover I do not see much harm in potential hypothetical config
inconsistency. The RTC sender if enabled will or will not send all RTs he
is interested in globally on a per session basis while the receiver will or
will not apply such filter on a per SAFI basis.

Due to lack of dynamic capabilities each change in such config will result
in session reset. Do we want to go that path ?

​Best,
r.​

> While this could control the local RTC processing, the point is with
> current RTC capability negotiation the BGP peer only knows that RTC is
> enabled on this session, and has no idea which AFI/SAFI on its peer is
> allowed by the local knob to process RTC. If on two peering speakers the
> knobs are enabled inconsistently, this cannot be found through BGP
> capability advertisement. Since RTC can work correctly only if the knob is
> enabled consistently in the network, it may be helpful to advertise the RTC
> capability of specific AFI/SAFIs.
>
>
>
> ​That was never subject of this discussion. It's completely separate
> change which does require changes to base spec.​
>
>
>
> #Jie: the MDT SAFI requires different RTC processing, and it warns us that
> some other address families may have similar requirement in future. This
> may be achieved either by AF specific update documents, or by some update
> to the base spec.
>
>
>
>
>
> #Jie: The default behavior for routes with no RTs may be different for
> different AFI/SAFIs, that’s why I brings the AFI/SAFI specific discussion
> here.
>
>
>
> I’m OK with continuing this per AFI/SAFI discussion separately, and I also
> prefer not to make major changes to base RTC if possible.
>
>
>
> Best regards,
>
> Jie
>
>
>