Re: [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 22 March 2022 07:08 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22833A012A; Tue, 22 Mar 2022 00:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNk_vJ54YdRK; Tue, 22 Mar 2022 00:08:03 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9CF3A00AF; Tue, 22 Mar 2022 00:08:03 -0700 (PDT)
Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KN2Zy67k5z686G1; Tue, 22 Mar 2022 15:06:18 +0800 (CST)
Received: from kwepemi500015.china.huawei.com (7.221.188.92) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 22 Mar 2022 08:07:59 +0100
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by kwepemi500015.china.huawei.com (7.221.188.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 22 Mar 2022 15:07:57 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2308.021; Tue, 22 Mar 2022 15:07:57 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "pim@ietf.org" <pim@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
Thread-Index: Adg0jgH6Vhd2qInSTIyLydPTNUZKHgH3fOsA
Date: Tue, 22 Mar 2022 07:07:57 +0000
Message-ID: <92fccbee7fdf460d8ace5471949a2dd5@huawei.com>
References: <00f301d8348e$e2ae8c40$a80ba4c0$@ndzh.com>
In-Reply-To: <00f301d8348e$e2ae8c40$a80ba4c0$@ndzh.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: multipart/alternative; boundary="_000_92fccbee7fdf460d8ace5471949a2dd5huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/EVx3dhN425q1Y4RsnFJT9f3JKOY>
Subject: Re: [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 07:08:08 -0000

Hi Sue and authors,

I've read the latest version of this document and have some questions,

I understand this document provides one mechanism to build P2MP Trees using the tree SIDs and the unicast SR SIDs.  While it is not quite clear to me how much it is analogous to SR policy, and whether BGP is the suitable tool for its provisioning.


1.       This document introduces 3 route types. The first route type is provisioned to the headend node (the root node), the second route type is used to provision the replication SID on each replication node individually, and the third route type is used to progress each outgoing interface individually for a replication cross connect.  This is different from SR Policy which only needs to be provisioned on the headend nodes of the path, and it seems that this is an extension to BGP for the provisioning of individual transit nodes and interfaces with different information.



2.       In this document, a P2MP candidate path carried in BGP tunnel encaps attribute consists of several path instances, one of the path instance is active, the others are used as backup paths. And under a path instance, it may contain a protection segment list.



While in BGP SR Policy,  the tunnel encaps attribute consists of multiple segment lists under one candidate path, and all the segment lists are used for load balancing purpose. Different candidate paths can be used as either active or backup paths, but they are carried with different SR Policy NLRIs. Since this document says it reuses the concept of candidate path, It would be helpful if it could highlight the difference from SR Policy candidate path in the structure.


Best regards,
Jie

From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:55 PM
To: idr@ietf.org; pim@ietf.org; bess@ietf.org
Subject: [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

1)  Does this technology support the SR P2MP features
that distributes candidate paths which connect
a multicast distribution tree (tree to leaves).

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?

3) Does the P2MP policy operation (section 4)
provide enough information for those implementing this
technology and those deploying the technology?

4) Do you think this multicast technology is a good
Place to start for P2MP policy advertisement via BGP?

5) Do you think this SR P2MP policies should not be advertised
via BGP?

Cheers, Susan Hares