Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022) - Extended an Additional week to 10/18/2022

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

Hi Jeffrey,

Please see inline with [Jie#2].

Best regards,
Jie

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Tuesday, October 25, 2022 8:04 PM
To: Dongjie (Jimmy) <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]
Subject: RE: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022) - Extended an Additional week to 10/18/2022

Hi Jie,

Please see zzh> below.



Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>>
Sent: Wednesday, October 19, 2022 4:56 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022) - Extended an Additional week to 10/18/2022

[External Email. Be cautious of content]

Hi Jeffrey,

Please see inline:

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Wednesday, October 19, 2022 11:05 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022) - Extended an Additional week to 10/18/2022

Hi Jie,

Draft-dong says:


   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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4364__;!!NEt6yMaO-gk!Hh1rXhslU4YoT-0qPG_PzdQ_j8k_T86Upirn45RkObVBMmZh0yBlOxnQWiKM0qe4YGOT378Nf-D0EetP_26E2Jr76dTUSDDn$>] was designed for the matching of

   VPN routes into the target VPN Routing and Forwarding tables (VRFs)

   on the PE nodes.  [I-D.ietf-idr-segment-routing-te-policy<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dong-idr-node-target-ext-comm-05*ref-I-D.ietf-idr-segment-routing-te-policy__;Iw!!NEt6yMaO-gk!Hh1rXhslU4YoT-0qPG_PzdQ_j8k_T86Upirn45RkObVBMmZh0yBlOxnQWiKM0qe4YGOT378Nf-D0EetP_26E2Jr76ZoarSbF$>] 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.  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.

   Thus a general mechanism which is independent from the control of VPN

   route to VRF import is needed.

The red text is not correct. RFC 6514 already used <address:0> RT to target routes to a node, and as you say in the purple text the RT mechanism can be extended to non-VPN.

[Jie] I guess you are referring to the use of ASBR Import RT? My understanding is that it is still an normal RT type (no new EC type assigned), thus the semantic and behavior would be the same as the RT.

Zzh> Indeed; the normal RT type can be used to target routes to a node (or a set of node if they are configured to import the same RT).

[Jie#2] Although this is one possible use of RT for specific AFI/SAFI (which does not have multiple VRFs), this is not the semantic of RT in general. RT is used to control the route importing to specific routing table (VRF).

The problem is as described in this section, if you use this RT together with another RT of specific VPN for distributing routes to one VRF of the target node,  as a result other nodes with the same VPN would also import this route to their VRFs.

Zzh> You would NOT use this with another RT of a VPN - that's the whole purpose of draft-zzhang. The routes will include an Extended Community derived from the VPN RT, which is used by the targeted nodes to import the routes into the VRF.

[Jie#2] Are you saying that you suggest to use a new type of EC (the value derived from the VPN RT) to replace the function of VPN RT, AND specify the group of target nodes? Then its functionality would overlap with that of RT, and you will need a large number of such ECs to cover the combination of every <VPN, target node group>.  I'm not sure this is a good idea. Also, the draft is not clear about how the target nodes are identified with the new EC.

As for the green text, draft-zzhang has a simple solution for it.

[Jie] I've read your draft. I don't think it address the "same" use case, such as targeted distribution of BGP Flowspec.

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Best regards,
Jie

Thanks.
Jeffrey



Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>>
Sent: Monday, October 17, 2022 11:32 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022) - Extended an Additional week to 10/18/2022

[External Email. Be cautious of content]

Hi Jeffrey,

Thanks for the information about another draft which is targeted at similar problems.

My reading is that it clearly shows in several use cases, there is requirement to define a separate EC type to control the propagation and importation of routes to targeted network nodes, and keep the semantics of RT as is for the importation of routes to specific routing tables.

The new EC type introduced in draft-dong-idr-node-target-ext-comm can achieve targeted route distribution without introducing additional policy configurations on network nodes.

Best regards,
Jie

From: Idr [mailto:[e-mail]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, October 18, 2022 9:30 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022) - Extended an Additional week to 10/18/2022

Almost missed it ... (sorry - have not got to check IDR list for a while).

Please note that I pointed out that there are (better?) alternatives than this: https://mailarchive.ietf.org/arch/msg/idr/tDDCFD7VftNMnYOqC0O3mSS0l0Q/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/tDDCFD7VftNMnYOqC0O3mSS0l0Q/__;!!NEt6yMaO-gk!Cgi7cyYJrEAuIxJiWl_OE5CbegKAEAzcViF9NcaVArITeXZdhwApF2v_KeTpWWYNKBOzvURpisakpyALQjMNvXww_gCzhtB4$>.
I also made a request to adopt the alternative solution (I'll reply to that email thread).

Thanks.
Jeffrey



Juniper Business Use Only
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: Wednesday, October 12, 2022 6:40 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022) - Extended an Additional week to 10/18/2022

[External Email. Be cautious of content]

I am extending this WG call 1 more week since the WG adoption call occurred during Chinese Holidays (October 1-7).

Cheerily, Susan Hares