Re: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover

zhang.zheng@zte.com.cn Tue, 15 March 2022 07:49 UTC

Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8903A19AE for <mboned@ietfa.amsl.com>; Tue, 15 Mar 2022 00:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=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, UNPARSEABLE_RELAY=0.001, 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 RUvyYMz_yOnI for <mboned@ietfa.amsl.com>; Tue, 15 Mar 2022 00:49:42 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925DC3A19A8 for <mboned@ietf.org>; Tue, 15 Mar 2022 00:49:41 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4KHltC3y8Jz85bHw; Tue, 15 Mar 2022 15:49:39 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id 22F7nU8r047246; Tue, 15 Mar 2022 15:49:30 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Tue, 15 Mar 2022 15:49:29 +0800 (CST)
Date: Tue, 15 Mar 2022 15:49:29 +0800
X-Zmail-TransId: 2afb62304509dcc534fa
X-Mailer: Zmail v1.0
Message-ID: <202203151549299959656@zte.com.cn>
In-Reply-To: <CCEA4102-79F3-48B8-AAC1-45584764E38A@akamai.com>
References: 8a58d44c-4cfa-1ebf-bb9f-71908b2bdae6@juniper.net, CCEA4102-79F3-48B8-AAC1-45584764E38A@akamai.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: jholland=40akamai.com@dmarc.ietf.org
Cc: lenny=40juniper.net@dmarc.ietf.org, mboned@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl2.zte.com.cn 22F7nU8r047246
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 62304513.002 by FangMail milter!
X-FangMail-Envelope: 1647330579/4KHltC3y8Jz85bHw/62304513.002/10.30.14.239/[10.30.14.239]/mse-fl2.zte.com.cn/<zhang.zheng@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62304513.002/4KHltC3y8Jz85bHw
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/fPiKiDnYZoAkX1v-MyIn-rMnyNc>
Subject: Re: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2022 07:49:45 -0000

Hi Jake, 
Thank you very much for your support and comments! 
Please find my answer below with Sandy>.


------------------原始邮件------------------
发件人:Holland,Jake
收件人:Leonard Giuliano;MBONED WG;
日 期 :2022年03月14日 19:27
主 题 :Re: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover
Hi mboned,
I support adoption.
I think this is a good start at outlining approaches to addressing an
important problem, and I can see how an informational doc like this
can be a reference for later docs that provide more fully articulated
solutions.
I have a few concerns* that might require some work, but I think they
can be fleshed out in review.
Best,
Jake
* Some specific concerns, at a high level:
1. the approaches described in section 4 seem to have a very BIER-centric
view.  For instance with PIM or P2MP I'm not sure it makes sense for an
ER to signal the IRs in the ways described, and there might have to be
either a different section to describe what makes sense or doesn't make
sense for networks that rely on tree-building, or to narrow this doc's
scope to BIER.
Sandy> In fact this section is not only used by BIER enviorment. 
The signaling between IR and ER can be used for multicast service management, the intermediate transport technologies can be BIER, P2MP or PIM. 
Although it seems like strange for PIM because PIM depends on tree building.
2. Related to #1, it's not clear how actionable the advice to network
operators in this doc is.  I'm not sure if it makes more sense to change
it to advice for future protocol or configuration modeling solutions, or
to add pointers to published examples of configurations that can implement
the given advice, but I think some work probably needs to happen to make
it more clear who the expected reader is and what they can do with the
information in the doc.
Sandy> The same with 1. This document only analyzes these technologies but not want to modify them. 
The motivation of this draft is let the network administrator select the suitable solution according to the exact deployment, since there is no the best solution.
For how to make it more clear for the reader, much appreciate if you will give more specific modification information.  
3. there are a lot of English language grammar issues, especially through
section 4.  IMO it makes it a little hard to read and to review, and it
might be helpful to get an early phase editorial pass
Sandy> Thank you! We will do some editorial changs for the grammer.
Best regards,
Sandy
On 03-11, 4:08 AM, "Leonard Giuliano" <lenny=40juniper.net@dmarc.ietf.org> wrote:
We would like to initiate an official call for adoption of the "Multicast
Redundant Ingress Router Failover" draft:
https://datatracker.ietf.org/doc/draft-szcl-mboned-redundant-ingress-failover/
Please respond on list by Mar 25 if you do/do not support adoption of this
draft in MBONED.
If you are listed as a document author, please respond to this email
whether or not you are aware of any relevant IPR. If you are not listed as
an author and are aware of any relevant IPR, please respond as well.
-Lenny
_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www.ietf.org/mailman/listinfo/mboned
_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www.ietf.org/mailman/listinfo/mboned