Re: [Pals] What should we do with draft-jiang-pwe3-mc-pon

shencb <shencb@sttri.com.cn> Thu, 12 March 2015 03:28 UTC

Return-Path: <shencb@sttri.com.cn>
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 5D94F1A88CF for <pals@ietfa.amsl.com>; Wed, 11 Mar 2015 20:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 3pUxOlxUqe-O for <pals@ietfa.amsl.com>; Wed, 11 Mar 2015 20:27:57 -0700 (PDT)
Received: from corp.21cn.com (corp.forptr.21cn.com [121.14.129.37]) by ietfa.amsl.com (Postfix) with ESMTP id F02341A8740 for <pals@ietf.org>; Wed, 11 Mar 2015 20:27:52 -0700 (PDT)
HMM_SOURCE_IP: 10.28.101.7:35552.1013128463
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from shenchb-nb (unknown [10.28.101.7]) by corp.21cn.com (HERMES) with ESMTP id 00046AC002; Thu, 12 Mar 2015 11:27:33 +0800 (CST)
Received: from shenchb-nb ([218.80.215.132]) by 21CN-ent7(MEDUSA 10.28.101.7) with ESMTP id 1426130852.14353 for stbryant@cisco.com ; Thu Mar 12 11:27:51 2015
0/X-Total-Score: -120:
X-FILTER-SCORE: to=<949583939a828f9561848a9484904f84908e8b8a828f889a96828f8d908f886189968298868a4f84908e91828d94618a8695874f90938885938287954e8b8a828f884e919886544e8e844e91908f619590908d944f8a8695874f909388>, score=<1426130871SYSSZS7YZaFG5yiSSSSS7SsSssosjSo5vIDc2sssssjs>
X-REAL-FROM: shencb@sttri.com.cn
X-Receive-IP: 218.80.215.132 shencb@sttri.com.cn
Date: Thu, 12 Mar 2015 11:27:31 +0800
From: shencb <shencb@sttri.com.cn>
To: stbryant <stbryant@cisco.com>, 蒋yuanlong <jiangyuanlong@huawei.com>, "pals@ietf.org" <pals@ietf.org>
References: <54F9B9CF.1010207@cisco.com>, <3B0A1BED22CAD649A1B3E97BE5DDD68B5A89549E@szxema506-mbs.china.huawei.com>, <550022DE.7000706@cisco.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 140[cn]
Mime-Version: 1.0
Message-ID: <2015031211272937057616@sttri.com.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart428728483803_=----"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/cfBznOGP0r6z33Y4P62XsLVPZgU>
X-Mailman-Approved-At: Wed, 11 Mar 2015 20:42:43 -0700
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: Thu, 12 Mar 2015 03:28:01 -0000

hi, everyone,
     in my opinion, for some large operators, if they deploy PON protection to provide good access network availability for business customers, MBH, and some special application such as surveilunce, the ICCP will be very benifitting. for China Telecom, We have deployed a great number of PON equipments, in some scenarios, we use trunk protection for business application. besides, we are trialing the MBH over PON as well as promoting the Broadband project SD-331 "Architecture and Technical Requirements for PON-Based Mobile Backhaul Networks", so an interoperable solution is attractive to us.
     the idea to push interoperability on it should be supposed as prefered. of course, other operators' point of view should be welcomed and discuss it further.
     Best Regards!
                                                             Shen Chengbin from China Telecom


沈成彬 主任
博士,教授级高工
中国电信股份有限公司上海研究院 基础网络部 
地       址:上海市浦东新区浦东南路1835号
邮       编:200122
电       话:021-28970176
手       机:18918588789
电子邮箱:shencb@sttri.com.cn

Champion(Chengbin) Shen Director
Ph.D, Senior Engineer (Professor Grade)
Dept. of Infrastructure Networks
Shanghai Research Institute of China Telecom Corp. Ltd.
Add: 1835 South Pudong Road, Shanghai, 200122, China
Tel : +86 21 28970176
Mobile: +86 18918588789
E-mail: shencb@sttri.com.cn
 
From: Stewart Bryant
Date: 2015-03-11 19:11
To: Jiangyuanlong; pals@ietf.org
CC: draft-jiang-pwe3-mc-pon@tools.ietf.org
Subject: Re: [Pals] What should we do with draft-jiang-pwe3-mc-pon
Yuanlong

I think the critical point in the thread was the express need for mult-vendor deployments, something that we are all used to in classical networks.

It would be useful to know how often multi-vendor PON is in practice deployed.

Stewart

On 11/03/2015 02:17, Jiangyuanlong wrote:
Hi Stewart,
 
The motive and situation is similar to ICCP, maybe the following mailing list can provide some reasons from SP’s viewpoint when that I-D was polled:
https://www.ietf.org/mail-archive/web/pwe3/current/msg10339.html
 
Actually, trunk protection (or Type B protection) for PON has been deployed by service providers in quite a few countries. There are also quite a few service providers interested in providing ICCP like synchronization for PON, this can be confirmed by our coauthors on the SP side.
 
Best regards,
Yuanlong
 
 
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


-- 
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html