答复: [nvo3] Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Haoweiguo <haoweiguo@huawei.com> Tue, 04 March 2014 08:51 UTC

Return-Path: <haoweiguo@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 468071A0417; Tue, 4 Mar 2014 00:51:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.803
X-Spam-Level: *
X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 CQhVhPOqSB5C; Tue, 4 Mar 2014 00:51:19 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 100891A0430; Tue, 4 Mar 2014 00:51:17 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBS47078; Tue, 04 Mar 2014 08:51:14 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 08:50:43 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 08:51:09 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 4 Mar 2014 16:51:05 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: Kanwar Singh <kanwar@nuagenetworks.net>, "nvo3@ietf.org" <nvo3@ietf.org>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: =?gb2312?B?tPC4tDogW252bzNdIFJlcXVlc3QgZm9yIGNvbW1lbnRzOiBkcmFmdC1qYWlu?= =?gb2312?Q?-nvo3-overlay-oam-01.txt?=
Thread-Topic: [nvo3] Request for comments: draft-jain-nvo3-overlay-oam-01.txt
Thread-Index: AQHPKb/Di4kU9SKxnU+FpAnzs/ScV5rQsawj
Date: Tue, 4 Mar 2014 08:51:04 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517334F7B6574@nkgeml501-mbs.china.huawei.com>
References: <CAPCgso0=mi+WuWzQg_YoaMmBgpkBYk8HWq3VijLnAKuBk9Rggw@mail.gmail.com>
In-Reply-To: <CAPCgso0=mi+WuWzQg_YoaMmBgpkBYk8HWq3VijLnAKuBk9Rggw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.101.75]
Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7B6574nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/a_XupWzdM6Vjpa7r5c2xTzPf-7Y
Cc: Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
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, 04 Mar 2014 08:51:22 -0000

Hi Authors,

Yesterday on L2VPN meeting site, i asked a question and please allow me to repeat the question here again.

Is the solution in your draft only supports unicast ping/trace? or both multicast and unicast ping/trace?

Because overlay network can support both unicast and multicast service, so OAM framework should include both unicast and multicast path connectivity verification functionality.



For unicast, relying on path trace mechanism in your draft, the underlying network fault can be located. Echo request are sent with incremental TTL of outer header, relying on underlying network ICMP function, the underlying network fault can be located.But for multicast traffic, it is hard to rely on this mechanism to locate detail underlying network error.



Further question:

In your draft,i think it has a assumption that underlying network for NVO3 should be IP network, but if underlying network is Ethernet, or TRILL, or SPB network, how can you locate detail underlying network fault?



thanks

weiguo



________________________________

发件人: Kanwar Singh [kanwar@nuagenetworks.net]
发送时间: 2014年2月14日 4:05
收件人: nvo3@ietf.org
抄送: Pradeep Jain; Anil Lohiya; Florin Balus; Kanwar Singh; Vinay Bannai; Ravi Shekhar; Wim Henderickx
主题: [nvo3] Request for comments: draft-jain-nvo3-overlay-oam-01.txt


Greetings All:

We have submitted the draft that proposes Generic Overlay OAM framework and Datapath Failures detection mechanisms.

Please review the same update us with your valuable comments/feedback.

Warm Regards,



- Authors


A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt



has been successfully submitted by Kanwar Singh and posted to the

IETF repository.


Name:           draft-jain-nvo3-overlay-oam

Revision:       01
Title:          Generic Overlay OAM and Datapath Failure Detection

Document date:  2014-02-12

Group:          Individual Submission

Pages:          44
URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt

Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/

Htmlized:      http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01

Diff:              http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-01


Abstract:

   This proposal describes a mechanism that can be used to detect Data

   Path Failures of various overlay technologies as VXLAN, NVGRE,

   MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data

   Plane for given Overlay Segment.  This document defines the following

   for each of the above Overlay Technologies:


   o  Encapsulation of OAM Packet, such that it has same Outer and

      Overlay Header as any End-System's data going over the same

      Overlay Segment.


   o  The mechanism to trace the Underlay that is exercised by any

      Overlay Segment.


   o  Procedure to verify presence of any given Tenant VM or End-System

      within a given Overlay Segment at Overlay End-Point.


   Even though the present proposal addresses Overlay OAM for VXLAN,

   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are

   generic enough to accommodate OAM for any other Overlay Technology.