[Idr] Comments about draft-dong-idr-node-target-ext-comm

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jie, Shuwan, Gunter,

   Currently BGP does not have a generic mechanism of designating the
   set of nodes to which the information is to be distributed.  Route
   Target (RT) as defined in [RFC4364] was designed for the matching of
   VPN routes into the target VPN Routing and Forwarding tables (VRFs)
   on the PE nodes. 

RFC6514 already uses IP address specific RTs to target routes to certain nodes. The receiving nodes then use other information to put the routes into appropriate VRFs.
Using other types of RTs to target a set of nodes should also work as a general mechanism.

   [I-D.ietf-idr-segment-routing-te-policy] introduces
   the mechanism of steering the SR Policy information to the target
   head end node based on RT, it is only applicable to the SR Policy
   Address Family.  

It should be no problem to use this for any address family.

   Although it is possible to reuse RT to control the
   distribution of non-VPN information to one or a group of receiving
   nodes, such mechanism is not applicable when the information to be
   distributed is VPN-specific and is advertised with another set of RTs
   for the VRF matching, as the matching or any of the VPN RT in the BGP
   route would result in that route being imported to a local VRF,
   regardless of whether the receiving node is the target node or not.

https://datatracker.ietf.org/doc/draft-zzhang-idr-rt-derived-community/ describes a generic method:
- Use a general-purpose RT to target nodes
- Use an extended community derived from the VPN RT to tell the targeted node that the route is associated with the VPN

   Another possible approach is to configure, on each router, a
   community and the corresponding policies to match the community to
   determine whether to accept the received routes or not.  Such
   mechanism relies on manual configuration thus is considered error-
   prone.  It is preferable by some operators that an automatic approach
   can be provided, which would make the operation much easier.

But the node advertising the route needs to know which targeted nodes to encode. That may not be straightforward.

   This document defines a new type of BGP Extended Community called
   "Node Target".  The mechanism of using the Node Target extended
   community to control the BGP route distribution only to particular
   BGP nodes is also specified.

This seems to complicate the RTC based route propagation:
- the RTC advertisements now need to include these new communities
- a logical AND criteria is needed
- if a route needs to go to several nodes, then each needs to be encoded by the source and compared against on each hop.

Jeffrey


Juniper Business Use Only