[Idr] Progress the solution part in draft-dong-idr-rtc-hierarchical-rr

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

Dear all,

The -00 version of draft-dong-idr-rtc-hierarchical-rr was submitted before the Toronto IETF meeting, and brought lots of discussions and good comments.

The earlier discussions can be classified into several categories of potential solutions as listed below (please correct me if some of the descriptions are not accurate enough). While the authors are open to discussion for a reasonable solution, based on the earlier discussions, our initial conclusion is that category #1 (like best external advertisement) or #2 (add-path) may set the basis for the final solution.

The authors plan to update the solution part of this draft before Honolulu. The earlier discussions on the solution space are summarized as below, the authors would like to hear more opinions based on this summary and revise the draft accordingly.

Earlier discussions (in categories):

#1. Modify the path advertisement rule for RTC route. The benefit is the changes are made to RTC mechanism itself, and it ensures that RTC can work in any scenarios without relying on other mechanisms.


*           This is initially proposed in the -00 version draft, which specifies sending an alternative RTC route to the source of the best RTC route, and rules to ensure that the path can pass the BGP loop prevention.


*           Adam questioned the efficiency of rule 3.2.i of RFC4684, and proposed a modified rule for RTC route advertisement. The proposed rule is to send a RTC route learned from another peer to the client peer which is the source of the best path, and the new rule should be generalized for all iBGP sessions and replace the existing rules 3.2.i/ii in RFC4684.


*           Shyam commented that the rules proposed by Adam sound like a best-external advertisement.


*           During IDR meeting in Toronto, Saikat said there is fundamental difference between RTC and normal routes, suggested to not do path selection for RTC route and advertise the routes needed.


#2. Using add-path to advertise more than 1 RTC routes. Hopefully at least one of the RTC routes can pass BGP loop prevention and be accepted by the peer RR. This has been discussed by many people in detail and could be a prime candidate. Our concern is this solution would rely on the deployment of add-path and manual configuration for identifying the lower layer RR peers.


*           Robert firstly suggested to use add-path on the RTC address family.


*           Stephane said people can expect that RTC works without relying on add-path or other knobs.


*           Adam said add-path on the RTC AF seems as the best option.


*           Jie mentions if use add-path, the rules of determining which RTC routes to advertise need to be specified, and then Robert suggests to use add-path "all".


*           Jeff suggests using add-path and normal BGP path advertisement rules within RRs hierarchy, and use the rules in RFC4684 3.2.i/ii with non-RR clients. The clients which are lower layer RRs needs to be identified via configuration.


#3. Advertise Default-RT route between the top RR and the lower layer RRs. Some concerns are raised during the discussion, and it may also need to work with add-path.


*           Robert suggested that the higher layer RR send default RTC route to lower layer RR, so lower-layer RR will send all vpn routes to the higher layer RR.


*           Xiaohu mentioned this may cause some VPN routes be advertised to the higher layer RR unnecessarily.


*           Jeff said the distribution of this default RTC route cannot be limited properly and may be advertised to PEs.



*           Jeff suggested that if add-path will be part of the solution, can send an add-path default RT-C route with "no-advertise" between the hierarchical RRs.


#4. Add RD into the RTC route to distinguish RTC routes from different originators, and use some aggregation mechanism. This will change the format of RTC NLRI, and the justification was queried.


*           Xiaohu proposed this suggestion and think it can work in any network scenario.


*           Robert said this is not backward compatible with RFC4684.


*           Jeff said the aggregation procedure would be messy.


#5. Replace the received Cluster-list with the RR's own Cluster-ID. This is similar to the rule 3.2.i of RFC4684 for ORIGINATOR_ID. This was discussed in detail and the agreement was to not modify BGP loop prevention mechanisms.


*           Stephane raised this suggestion, while he thought this may cause inefficient route distribution.


*           Robert said this may cause RTC update loop between the RRs.


*           Jeff said making changes to loop prevention mechanism may cause problem, and changes to the cluster-list manipulation in route reflection may cause convergence issue for RTC route, and consequently impact the VPN routes advertisement.



*           Stephane agreed that touching the loop prevention mechanism may cause some issue.

Best regards,
Jie