Re: [Pals] What should we do with draft-jiang-pwe3-mc-pon
Edwin Mallette <edwin.mallette@gmail.com> Wed, 11 March 2015 13:54 UTC
Return-Path: <edwin.mallette@gmail.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1091AC41E for <pals@ietfa.amsl.com>; Wed, 11 Mar 2015 06:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.813, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 zzlAK4hbne0o for <pals@ietfa.amsl.com>; Wed, 11 Mar 2015 06:54:34 -0700 (PDT)
Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DB51A890A for <pals@ietf.org>; Wed, 11 Mar 2015 06:54:34 -0700 (PDT)
Received: by qcyl6 with SMTP id l6so10216502qcy.13 for <pals@ietf.org>; Wed, 11 Mar 2015 06:54:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-type; bh=706bo59Xj09/KJxoGSBg/utMtXvGreUPAtvbYFadwVA=; b=awgxzOG4GltaUe+mx2l71PBkN/Bnrf9PT23Hw13kOS08oeu771DpkBSAky18Dpi/vL WIz7IHreSzcvDekCJcqDCJ1MRiiZF/3Lp3q2UEZAzQ8k+Fbe5MIU27jyqtnTl1FRKGyK RjyAQocwbZFv26R6ZHlK2t/Wp45RjluP/Li0WktEOlX2XH0aJsH9gfA72sI4Ag1ADijX pRO1I9eyfUPvNoVV6AKLJiZCIUBElMfyOl1LwvTSEK0DCjEeO6yWE9h3eH41oLlExyRt /1lj73YEWKLbXriq2rXjT+9N9Zt0SF3edJk9QcKdgOLXBnWL2oP/0hheXblyJKLx9wSs TuOQ==
X-Received: by 10.140.102.165 with SMTP id w34mr47711254qge.26.1426082073588; Wed, 11 Mar 2015 06:54:33 -0700 (PDT)
Received: from [192.168.0.120] (rrcs-97-76-236-4.se.biz.rr.com. [97.76.236.4]) by mx.google.com with ESMTPSA id 80sm2577611qhb.26.2015.03.11.06.54.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 06:54:32 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Wed, 11 Mar 2015 09:54:24 -0400
From: Edwin Mallette <edwin.mallette@gmail.com>
To: "Hongyu Li (Julio)" <hongyu.li@huawei.com>, "stbryant@cisco.com" <stbryant@cisco.com>, "pals@ietf.org" <pals@ietf.org>
Message-ID: <D125BE7B.79955%edwin.mallette@gmail.com>
Thread-Topic: [Pals] What should we do with draft-jiang-pwe3-mc-pon
References: <54F9B9CF.1010207@cisco.com> <6EB34CB5D82C4645B826C56144826EA97EB13B8F@SZXEMA509-MBX.china.huawei.com>
In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97EB13B8F@SZXEMA509-MBX.china.huawei.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3508912475_17117244"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/7gAa7PfpUbqvJGbL8HBiKOKgLyA>
Cc: "draft-jiang-pwe3-mc-pon@tools.ietf.org" <draft-jiang-pwe3-mc-pon@tools.ietf.org>
Subject: Re: [Pals] What should we do with draft-jiang-pwe3-mc-pon
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 13:54:38 -0000
To add my two cents, IEEE 1904.1 addressed specific layer2 messaging to enable PON protection for EPON access networks for both tree protection and trunk protection. I agree with Hongyu that trunk protection (Type B) is the most typical protection method in PON deployment. Similar to the ITU-T, IEEE1904.1 left a hole for trunk protection as the inter-system sync method was not defined and was determined to be out of scope of the project. This was left to other SDOs/future projects to address. And to respond to Stewarts question about multiple vendors in the PON space, we (as an network operator) currently have three different vendors EPON OLTs deployed and in production. One goal of IEEE1904.1 was to enable interoperability and we have had quite a bit of success there. Regards. Ed From: "Hongyu Li (Julio)" <hongyu.li@huawei.com> Date: Wednesday, March 11, 2015 at 8:31 AM To: "stbryant@cisco.com" <stbryant@cisco.com>, "pals@ietf.org" <pals@ietf.org> Cc: "draft-jiang-pwe3-mc-pon@tools.ietf.org" <draft-jiang-pwe3-mc-pon@tools.ietf.org> Subject: Re: [Pals] What should we do with draft-jiang-pwe3-mc-pon With my knowledge in PON and Access Network, Type-B protection is the most typical protection method in PON deployment and is the most cost-effective one. As PON technology is providing bandwidth up to 10 Gbps, it can be applied to more scenarios than ever. ITU-T has left a big hole for type-B to be deployed at large without defining the method of sync between two OLT devices. Obviously, IETF is in a much better position to fill the gap by enhancing ICCP. Fully support this draft moving forward. Hongyu From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Friday, March 06, 2015 10:30 PM To: pals@ietf.org Cc: draft-jiang-pwe3-mc-pon@tools.ietf.org Subject: [Pals] What should we do with draft-jiang-pwe3-mc-pon The authors of http://datatracker.ietf.org/doc/draft-jiang-pwe3-mc-pon/ have asked us to start a poll for WG adoption. However before we do this I think that we as a WG need discuss the right way forward for this draft. In looking at the history of the draft I discover that there has been almost no technical discussion on the list. If I look back at the minutes I find: @ IETF 90 YJS: how much is deployed with the 2:n splitters? Ed: Bright House would probably do it. The splitter would be in house as it solves other issues. PON is growing, but not a great deal deployed in NA cable. Yuanlong: used for small cell backhaul. Can protect a bunch of small cells. YJS: so far interest in, but not deployed. 2:N splitter needs to resynch. Why do we need if phy not there. Andy: please provide comments to the list. Matthew: readers? 4, only one commenter on the list and @ IETF 91 Edwin presented the slides No comments. The call for WG adoption will be carried to the email list. The Chairs noted interest in the meetings and on the list. In the last remark we may have been mistaken given that all I can find are eight emails up to this point excluding automatic notifications and emails from the authors asking the chairs to take an action. In looking at the draft, the only IANA actions are in the ICC RG parameter registry which has Expert Review or FCFS codepoint ranges, thus there is no need for a standards track RFC or indeed any RFC from this point of view. In looking at the subject matter itself, I wonder whether this is a technology where it is expected there will be multi-vendor deployment within a PON domain requiring multi-vendor interworking of this feature. The IESG have recently been pushing back on the publication of drafts that have limited support, and thus we need to be in a position to justify moving forward with this draft on whatever stream we decide is best. Given the above, I would like to understand the views of the WG on which stream is most appropriate for this work: PALS WG - Standards Track PALS WG - Informational AD sponsored Independent Stream What are the views of the PALS WG on how we should move forward and why? - Stewart _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals
- Re: [Pals] What should we do with draft-jiang-pwe… zhouguangtao
- Re: [Pals] What should we do with draft-jiang-pwe… Mingui Zhang
- [Pals] 答复: What should we do with draft-jiang-pwe… Puyun
- Re: [Pals] What should we do with draft-jiang-pwe… Dongjie (Jimmy)
- Re: [Pals] What should we do with draft-jiang-pwe… weiqiang cheng
- [Pals] What should we do with draft-jiang-pwe3-mc… Stewart Bryant
- Re: [Pals] What should we do with draft-jiang-pwe… Jiangyuanlong
- Re: [Pals] What should we do with draft-jiang-pwe… Stewart Bryant
- Re: [Pals] What should we do with draft-jiang-pwe… Hongyu Li (Julio)
- Re: [Pals] What should we do with draft-jiang-pwe… Edwin Mallette
- Re: [Pals] What should we do with draft-jiang-pwe… Jiangyuanlong
- Re: [Pals] What should we do with draft-jiang-pwe… shencb