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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Robert,

Thanks for your comments, please see my replies inline:

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

Jie,

In my understanding, this implies two things:

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

​Yes.​

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

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

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