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

Hi Robert,

In SAFI 134, RT is normally used for VRF filtering in VPN scenarios. IP-based RT may also be used for receiver node filtering. In this case, extra RT-based policies is needed on the receiver nodes.

It's same for SAFI 133, extra policies need to be configured on network nodes. While operators prefer an automatic approach.

SR-Policy is a new address family for transport tunnels only. RTs are introduced only for receiver node filtering. While for address families which are related to VPN services, the use of RTs has been specified, matching of any one of the RTs with a local VRF would result in the route being imported, no matter whether the receiver node is matched or not.

We need to consider a general mechanism for the receiver node filtering for different address families. The new Node-Target EC is introduced for this purpose.  It can also be used combined with RT for receiver node & VRF filtering without any ambiguity.

Regards,
Haibo

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Saturday, October 8, 2022 3:52 PM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
Cc: Susan Hares <shares@ndzh.com>; idr@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

Haibo,

> .. directly filtering the receiver based on the RT.
> However, this method is not applicable to some old address families, such as Flowspec.

That is incorrect.

Since day one of RFC5575 - FlowSpec uses RT to filter it's UPDATEs. Please see description for SAFI 134. It is also RTC compatible.

Note that RT filtering can also be applied to SAFI 133.

Thx,
Robert.

On Sat, Oct 8, 2022 at 4:28 AM Wanghaibo (Rainsword) <rainsword.wang=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Hi Sue and WG,

I support the adoption of this draft.

Currently, more and more information is delivered by using the extended BGP address family through the controller.
Different from traditional BGP flooding, this mode requires filtering at the receive end. For example, the SR-Policy defines the method of directly filtering the receiver based on the RT.
However, this method is not applicable to some old address families, such as Flowspec. Therefore, it is necessary to introduce a common filtering mechanism at the receive end.

Best Regards,
Haibo

From: Susan Hares [mailto:shares@ndzh.com<mailto:shares@ndzh.com>]
Sent: Wednesday, September 28, 2022 1:30 AM
To: idr@ietf.org<mailto:idr@ietf.org>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>; Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>
Subject: draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

This begins a 2 week WG adoption and IPR call for draft-dong-idr-node-target-ext-comm-05.txt.
https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/

The authors should respond to this email with an IPR statement.

The WG should consider in their discussion:
1) Will this new  transitive extended community help
in operational networks?

2) What conflicts does this new Extended Community have
with other functions in general BGP route distribution or
VPNs (EVPN, IPVPN)?

3) do you have any concern about the text in the draft?

Cheerily, Sue
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr