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

[Robert Raszuk <[e-mail]>]

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 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.
>
>
>
> 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.​
>
>
>
> #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.
>
>
>
>
>
> 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).
>
>
>
> #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
>
>
>