Re: [Idr] draft-dong-idr-node-target-ext-comm route distribution procedures

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

Hi Jeff,

Thanks a lot for your review and comments on this document. 

The essence of this document is to introduce a new extended community type (NT), which can be used by a receiving BGP node to determine whether it is the target node or not. 

Regarding the distribution procedure, as described in the updated version, by default RR does not take the NT into consideration in route distribution. This is analogous to the processing of VPN routes without RT-Constrain. 

That said, this document tries to introduce an optional procedure to improve the route distribution efficiency based on NT. It could be considered as a starting point for further discussion. The authors realized that this optional procedure may or may not work in different network scenarios (e.g. the deployment of hierarchical RRs), thus whether it can be enabled needs depends on the operators policy and understanding to their network. This policy also needs to apply to the EBGP peer case (Sorry the current version is not very clear on this).

Your suggestion about using RT-constrain for this distribution control is interesting and deserve some further discussion. And in the controller based route distribution case, BGP-LS may also be an option to build the distribution graph on RRs. Actually this makes me wonder whether it would be better if we split the optional distribution optimization from the NT extended community definition in this draft. What do you think?

Best regards,
Jie

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Thursday, October 20, 2022 6:11 AM
> To: [e-mail]; [e-mail]
> Subject: draft-dong-idr-node-target-ext-comm route distribution procedures
> 
> Authors,
> 
> As noted in other threads, I personally think the use case for targeting a
> specific node is clear in terms of community addressing.  I have a number of
> concerns about the distribution machinery portion of your draft.
> 
> I would roughly summarize your proposal as an attempt to flood the routes
> with this extended community through the AS and have them land only on
> the expected device.
> 
> In a fully-meshed iBGP network, an implementation can always know what
> its attached iBGP BGP Identifiers are.  So, it's possible to target routes to
> such nodes immediately.
> 
> In a network with route reflectors, given the lack of the BGP Identifier
> distribution graph, your strategy is "just pass it through the reflectors".
> I would observe that a route reflector may know that it is a route reflector,
> but may not know that its peer is also a route reflector.  This means you
> can't do selective propagation without this knowledge.
> 
> Finally, while you generally place inter-domain "for further study", you do
> cover the eBGP case when an adjacent router has a local match for itself and
> then it looks for the adjacent eBGP match.
> 
> If my summary of the procedures is roughly correct, this is an attempt to try
> to do work that would be more easily covered by simply using RT-Constrain.
> For an N node network, you'd have N RT-Constrain routes which will build
> the necessary flooding graph as per the usual procedures.  eBGP routers
> could signal into that either directly via RT-Constrain eBGP procedures;
> alternatively, the ASBRs could emit a RT-Constrain route for each of their
> eBGP neighbors by proxy.
> 
> Of course, there's one large hold-up with regard to such a methodology:
> RT-Constrain is not per-AFI/SAFI for its flooding graph.  In general, this
> hasn't been a problem for features deployed for RT-Constrain since the
> communities in question tend to be associated with specific AFI/SAFIs.
> However, there's no guarantee that a given AFI/SAFI node-targeted route has
> an appropriately congruent AFI/SAFI flooding topology along the
> RT-Constrain graph.
> 
> Solving the RT-Constrain AFI/SAFI congruency issue may be helpful here, and
> perhaps has overlapping use with other possible BESS use cases.
> 
> -- Jeff