IETF Logo Mail Archive

Re: [mpls] draft-allan-pim-sr-mpls-multicast-framework and MPLS

Xiejingrong <xiejingrong@huawei.com> Thu, 19 July 2018 18:53 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058A9130E33 for <mpls@ietfa.amsl.com>; Thu, 19 Jul 2018 11:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Level:
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, SPF_PASS=-0.001] autolearn=no 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 zLvfvqE0HvyY for <mpls@ietfa.amsl.com>; Thu, 19 Jul 2018 11:53:13 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48F712426A for <mpls@ietf.org>; Thu, 19 Jul 2018 11:53:12 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 35EE4721D0896; Thu, 19 Jul 2018 19:53:07 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 19 Jul 2018 19:53:08 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0382.000; Fri, 20 Jul 2018 02:52:59 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: David Allan I <david.i.allan@ericsson.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] draft-allan-pim-sr-mpls-multicast-framework and MPLS
Thread-Index: AQHUH5G2WPh3b/KOhUmyQOKPP8vWQQ==
Date: Thu, 19 Jul 2018 18:52:59 +0000
Message-ID: C13996CA-E449-4DAA-9600-52691BBD1FB6
References: <CY1PR15MB0874DBD84F813F609D4121DDD0520@CY1PR15MB0874.namprd15.prod.outlook.com>
In-Reply-To: <CY1PR15MB0874DBD84F813F609D4121DDD0520@CY1PR15MB0874.namprd15.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_C13996CAE4494DAA960052691BBD1FB6_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/MFg6Er1atp2a754erD-xmQpGdTs>
Subject: Re: [mpls] draft-allan-pim-sr-mpls-multicast-framework and MPLS
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 18:53:15 -0000

Hi Allan
I really think the algorithm is very strong to calculate a very optimized tree, but the usage of the strong algorithm in the draft is complex and many people may do not like, especially when considering the implementation cost and the benefits.
So i suggest deviding things into two parts, one is algorithm like rfc7811, and one is the possible usage of the algorithm like rfc7812 and etc. The later one can be open to some others to make better benefits according to their usecase or solution.
But I don't know if a pure algorithm draft without a good enough applicability temporaryly can make this more acceptable or not.Just my comment.

Thank you to introduce a strong tree computing algorithm.

Jingrong

--------------------------------------------------
Sent From WeLink
From:David Allan I
To:mpls@ietf.org,
Date:2018-07-19 14:26:24
Subject:[mpls] draft-allan-pim-sr-mpls-multicast-framework and MPLS

Hi MPLS folks

Re: https://datatracker.ietf.org/doc/draft-allan-pim-sr-mpls-multicast-framework/

In presentations of this draft, the question has been repeatedly raised “is this approach confined to SR-MPLS?”. At the mike Loa suggested I post this to the MPLS list for discussion.

Our first blush take is this looks doable but would require some SR-MPLS scaffolding to handle the multicast SID:

  1.  The LDP mesh would have no trouble stunt doubling for the SR-MPLS node SIDs.
  2.  An SRGB would be required to permit the equivalent of a binding SID for the multicast SID to be advertised, and mapping to local implementation of the SRGB.  Overall procedures would be a hybrid of SR-MPLS CP components, and LDP signaled labels for the unicast tunnels.

But I would invite the group to comment and potentially disabuse us of this notion 😊

Cheers
Dave & Co

v2.23.0 | Report a Bug | By Email