comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

"Xialiang (Frank)" <frank.xialiang@huawei.com> Tue, 18 March 2014 07:07 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7311A0039 for <l2vpn@ietfa.amsl.com>; Tue, 18 Mar 2014 00:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 zbhalLXS9PrD for <l2vpn@ietfa.amsl.com>; Tue, 18 Mar 2014 00:07:44 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 603591A065F for <l2vpn@ietf.org>; Tue, 18 Mar 2014 00:07:43 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER29005; Tue, 18 Mar 2014 07:07:34 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 07:07:31 +0000
Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 07:07:34 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.203]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 15:07:27 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "ssalam@cisco.com" <ssalam@cisco.com>, "sajassi@cisco.com" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" <jdrake@juniper.net>
Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":
Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":
Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2g==
Date: Tue, 18 Mar 2014 07:07:26 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F10F3DFF09@SZXEMA502-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.42.220]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F10F3DFF09SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/UeKencOiLqFq4JqJ9p6EawZZFto
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 07:07:46 -0000

Hi authors,
I have reviewed this important draft, and have some comments as below:
1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity point of view, I think there are some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scalability, Transport/Application Independence;
2. In section 3.1.1.1, what is the definition of per user flow? Why is it different to support it between E-VPN Network OAM and E-VPN Service OAM?
3. In section 3.1.1.1, does the section of "a representative path" mean using test flow to detect the node failure? if yes, how to do? Is it a necessary requirement of proactive fault detection?
4. In section 3.2.1, I do not quite understand the describing reason for the inaccuracy of Loss Measurement. Do you mean that test packets of Loss Measurement are all BUM packets? Can you clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packets for Loss Measurement?

Hoping for your feedback~~

B.R.
Frank