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

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Mon, 28 March 2022 09:26 UTC

Return-Path: <xiejingrong@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 BA08A3A1091; Mon, 28 Mar 2022 02:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.805
X-Spam-Level:
X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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=unavailable 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 SHW4CHmgLTNu; Mon, 28 Mar 2022 02:26:13 -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 1F0EA3A108F; Mon, 28 Mar 2022 02:26:13 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KRnLh2rrhz67lRg; Mon, 28 Mar 2022 17:23:40 +0800 (CST)
Received: from kwepeml500002.china.huawei.com (7.221.188.128) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 28 Mar 2022 11:26:08 +0200
Received: from kwepeml500002.china.huawei.com (7.221.188.128) by kwepeml500002.china.huawei.com (7.221.188.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 28 Mar 2022 17:26:07 +0800
Received: from kwepeml500002.china.huawei.com ([7.221.188.128]) by kwepeml500002.china.huawei.com ([7.221.188.128]) with mapi id 15.01.2308.021; Mon, 28 Mar 2022 17:26:07 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>
CC: "idr@ietf.org" <idr@ietf.org>, Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>, "pim@ietf.org" <pim@ietf.org>, BESS <bess@ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>
Thread-Topic: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call
Thread-Index: Adg0k0r8SPpUu5oNRbilwxi9GChogALn6MxQAADh+IAAi8nuoP//r14A//9zHPA=
Date: Mon, 28 Mar 2022 09:26:07 +0000
Message-ID: <22e89eb8e5a4404e8727f5a168c777ad@huawei.com>
References: <011e01d83493$6175b310$24611930$@ndzh.com> <BL0PR05MB56524EE412C4938C8083E3BED41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <BL0PR05MB56523E436FBC1353208E9A77D41A9@BL0PR05MB5652.namprd05.prod.outlook.com> <CO1PR05MB8314FCAD91B5E8CFF3A283D9D51D9@CO1PR05MB8314.namprd05.prod.outlook.com> <CAOj+MMHyrGudTrckVQZxY01J=w1iZqagXXDvYKLasDmrNdE3xQ@mail.gmail.com>
In-Reply-To: <CAOj+MMHyrGudTrckVQZxY01J=w1iZqagXXDvYKLasDmrNdE3xQ@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.232.176]
Content-Type: multipart/alternative; boundary="_000_22e89eb8e5a4404e8727f5a168c777adhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/QdDdrIHvQFG3JRHkjYvx1BaWMWk>
Subject: Re: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call
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: Mon, 28 Mar 2022 09:26:18 -0000

Hi,

I have always had my opinion that Multicast Tree Building procedure is a very dynamic procedure, however BGP is skilled at stable-data (like prefix, or aggregated MVPN state on edge of a provider) driven “PUSH” thing.

I have almost forget the detail of the draft-ietf-bess-bgp-multicast-controller through I had read it long ago.

I would suggest that the relationship of the draft-ietf-bess and the polling draft can be re-evaluated.

Thanks,
Jingrong


From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, March 28, 2022 4:47 PM
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org; Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>; pim@ietf.org; BESS <bess@ietf.org>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>
Subject: Re: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Hi,

It also needs to be observed that  draft-ietf-bess-bgp-multicast-controller has a broader scope and also covers mLDP functionality what may be extremely useful for networks which are not green field and would like to transition from current to new multicast trees.

Having solution in IDR which covers multicast tree setup partially and at the same time a more complete one which has been already adopted and is progressing as a WG document is never a good thing.

Besides I am puzzled since when IDR is accepting protocol extensions which are used to setup multicast distribution trees ?

When the first version of the draft was written (Sep 2017) we went to BESS with draft-ietf-bess-bgp-multicast-controller since that WG is center of gravity for all VPN/multi-tenant multicast related work.

Kind regards,
Robert


On Mon, Mar 28, 2022 at 7:39 AM Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
WG,

I agree with Jeffrey that the BESS adopted draft draft-ietf-bess-bgp-multicast-controller provides
Solution in the same problem space. It is good to discuss the two drafts before adopting
draft-hb-idr-sr-p2mp-policy in IDR.

Rgds
Shraddha



Juniper Business Use Only
From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 8:17 PM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: 'pim@ietf.org<mailto:pim@ietf.org>' <pim@ietf.org<mailto:pim@ietf.org>>; 'BESS' <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]

[+ BESS, PIM]

Hi,

I realized that in a hurry I did not respond to the specific questions below. Please see zzh> next to the questions.

Looks like that there are some comments on BESS/PIM list and I will go through those to see if I have any addition/follow-up on those.



Juniper Business Use Only
From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]

I am sorry for responding late. I somehow missed this.

I think we should discuss the relationship with daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey



Juniper Business Use Only
From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]

IDR WG:

If you just wish to respond to the IDR list,
you may respond to this email on the adoption call.

Cheers, Sue

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: idr@ietf.org<mailto:idr@ietf.org>; pim@ietf.org<mailto:pim@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: [Idr] 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>

In your comments for this call please consider:

Zzh> I want to point out that https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!VA2RfAmcBA46YljU7KP0svRjk7kWVgXhzfsGzul45PZ5GQ32gWZgaclSIG0DaUH9$> is another way to do the same. I also explained in https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!VA2RfAmcBA46YljU7KP0svRjk7kWVgXhzfsGzul45PZ5GQ32gWZgaclSICdM0D1B$> why it was in the bess WG.
Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP besides SR-P2MP) using a consistent way.

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

Zzh> It is one way to use BGP to support that. The bess draft specifies another way.

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

Zzh> The specified SAFI and tunnel encapsulation attribute additions are one way for the BGP signaling for SR-P2MP. The bess draft specifies another way.

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?

Zzh> Both ways are good place to start. We just need to figure out how to proceed with the two proposals.

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

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to discuss the two ways and figure out how to proceed. The authors have discussed before though we have not reached consensus.
Zzh> Thanks!
Zzh> Jeffrey

Cheers, Susan Hares
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess