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 Jeffrey Z

Let me know if I understand your draft below correctly.   It sounds like
the goals of the draft are similar to

https://datatracker.ietf.org/doc/html/draft-zzhang-idr-rt-derived-community-00

The goal of the RT derived extended community is in a use case where you
want to import IP VPN, EVPN or MVPN routes into a subset of PEs and not all
the PEs associated with an RT importation.  In your example in the draft
you specify RT1 / EC1 is imported my 10 PEs.  To control the importation of
routes EC3/RT3 is attached.  So EC3/RT3 is attached to a set of prefixes
that we want imported into a subset of PEs.  So this process of tacking on
EC for additional filtering and importation is commonly used for IP VPN and
can apply to EVPN or MVPN.   So that’s one option to solve the problem.

As an alternative for IP VPN, EVPN or MVPN your proposal adds on the new
derives RT  per the draft.

What are the advantages of using a derived extended community versus just
allocating a new RT for a subset of PEs to do the importation.

Also Jie’a  draft  seems similar but does your draft provide a solution for
the same use cases.

Kind Regards

Gyan

On Tue, Oct 18, 2022 at 11:06 PM Jeffrey (Zhaohui) Zhang <zzhang=
40juniper.net@dmarc.ietf.org> wrote:

> 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://datatracker.ietf.org/doc/html/rfc4364>] 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://datatracker.ietf.org/doc/html/draft-dong-idr-node-target-ext-comm-05#ref-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.  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.
>
>
>
> As for the green text, draft-zzhang has a simple solution for it.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>
> *Sent:* Monday, October 17, 2022 11:32 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Susan Hares <
> shares@ndzh.com>; idr@ietf.org
> *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:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Tuesday, October 18, 2022 9:30 AM
> *To:* Susan Hares <shares@ndzh.com>; idr@ietf.org
> *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 <idr-bounces@ietf.org> *On Behalf Of *Susan Hares
> *Sent:* Wednesday, October 12, 2022 6:40 PM
> *To:* idr@ietf.org
> *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
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*