Re: [Pals] Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)

Jiangyuanlong <jiangyuanlong@huawei.com> Wed, 14 September 2016 02:39 UTC

Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBFC12B523; Tue, 13 Sep 2016 19:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.729
X-Spam-Level:
X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 dXtKhU3jfW3i; Tue, 13 Sep 2016 19:39:56 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0DF12B173; Tue, 13 Sep 2016 19:39:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWD92873; Wed, 14 Sep 2016 02:39:52 +0000 (GMT)
Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 14 Sep 2016 03:39:50 +0100
Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.3]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Wed, 14 Sep 2016 10:39:39 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)
Thread-Index: AQHSDhnrM2JeV5n1TUKGxeOCmD2ke6B4MO/A
Date: Wed, 14 Sep 2016 02:39:39 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B9175EEE0@szxema506-mbs.china.huawei.com>
References: <147381075416.13170.14909169380037916813.idtracker@ietfa.amsl.com>
In-Reply-To: <147381075416.13170.14909169380037916813.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.203.119]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57D8B878.019E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.3, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 36a30ee8211babaf5cb8b41d26a78a84
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/0j4aGiWgQBnpAht49cpSye1Vi4U>
Cc: "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "agmalis@gmail.com" <agmalis@gmail.com>, "draft-ietf-pals-mc-pon@ietf.org" <draft-ietf-pals-mc-pon@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [Pals] Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 14 Sep 2016 02:40:00 -0000

Hi Stephen,

To be clear, it is proposed to add "in a single administrative domain" to the end of "this ICCP application SHOULD only be used in
   well-managed and highly monitored service provider PON access networks..." 
Thus we have the following texts "this ICCP application SHOULD only be used in
   well-managed and highly monitored service provider PON access networks in a single administrative domain".

Typically, the PON network and the MPLS network interconnection as described in the document (for scenarios including FTTx, MSO and mobile backhaul) are under the control of a single service provider. So the proposed change does not inflict any real constraint.

ICCP is a sub-type of LDP protocol (RFC5036), the same security measures of LDP are applicable too, that is, ICCP peer PEs (LDP peers) are in the same MPLS administration domain, access list and authentication mechanisms can be used between the PEs (e.g., all LDP packets are denied by the OLT if they are received from the interfaces connecting the ONUs). As this document is based on ICCP (i.e., LDP), we can use all these mechanisms described in RFC5036 and RFC7275.

Are you satisfied with this resolution? Do you have any suggestions?

Thanks,
Yuanlong


-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
Sent: Wednesday, September 14, 2016 7:53 AM
To: The IESG
Cc: draft-ietf-pals-mc-pon@ietf.org; Andrew G. Malis; pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org
Subject: Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)

Stephen Farrell has entered the following ballot position for
draft-ietf-pals-mc-pon-04: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-mc-pon/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Is this extension to ICCP really compatible with section
10 of RFC7275?  RFC7275 says "It ought not be deployed on or over the public Internet.  ICCP is not intended to be applicable when the Redundancy Group spans PEs in different administrative domains" whereas this draft only refers to the "well-managed" stuff and says nothing about multiple domains, and this draft also refers to public contexts such as telephone poles. Can you justify for me how using ICCP here is safe? (It may well be, but I'm entirely unsure, probably mostly due to my ignorance of PON deployments.)

The same point was made in the secdir review [1] which did get a response. Sadly, I didn't get how the response answered the question. 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06762.html