Re: [trill] WG Last Call - draft-ietf-trill-oam-fm

"Xialiang (Frank)" <frank.xialiang@huawei.com> Mon, 31 March 2014 03:01 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807F81A0936 for <trill@ietfa.amsl.com>; Sun, 30 Mar 2014 20:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ziMVLarMU0JN for <trill@ietfa.amsl.com>; Sun, 30 Mar 2014 20:01:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3CED11A0934 for <trill@ietf.org>; Sun, 30 Mar 2014 20:01:22 -0700 (PDT)
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 BCO68820; Mon, 31 Mar 2014 03:01:18 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 31 Mar 2014 04:00:30 +0100
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; Mon, 31 Mar 2014 04:01:17 +0100
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; Mon, 31 Mar 2014 11:01:11 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>, Donald Eastlake <d3e3e3@gmail.com>
Thread-Topic: [trill] WG Last Call - draft-ietf-trill-oam-fm
Thread-Index: AQHPOjNr1ILWnQFjrUWrg8zEpIRha5repI+ggBmFfQCAAmLpgA==
Date: Mon, 31 Mar 2014 03:01:11 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F10F3E1906@SZXEMA502-MBS.china.huawei.com>
References: <CAF4+nEEa58e=Q8w3znDaEvP0CSqHZEKp7--b+3TH=LSPE4zaQw@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F10F3DF424@SZXEMA502-MBS.china.huawei.com> <FBEA3E19AA24F847BA3AE74E2FE193562AFA42AA@xmb-rcd-x08.cisco.com>
In-Reply-To: <FBEA3E19AA24F847BA3AE74E2FE193562AFA42AA@xmb-rcd-x08.cisco.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/0GtsqGWImnCJ6t2a0ON0uIR036M
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] WG Last Call - draft-ietf-trill-oam-fm
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 03:01:24 -0000

Tissa
I agree with your clarification. One more suggestion: For clarity, some words need to be added to describe how to ensure all CCMs belonging to a flow to go through the same path.

B.R.
Frank

> -----Original Message-----
> From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
> Sent: Sunday, March 30, 2014 5:03 AM
> To: Xialiang (Frank); Donald Eastlake
> Cc: trill@ietf.org
> Subject: RE: [trill] WG Last Call - draft-ietf-trill-oam-fm
> 
> Frank
> 
> Thanks for going through the draft and careful review. Please see in -line the
> answers
> 
> -----Original Message-----
> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Xialiang (Frank)
> Sent: Thursday, March 13, 2014 12:20 AM
> To: Donald Eastlake
> Cc: trill@ietf.org
> Subject: Re: [trill] WG Last Call - draft-ietf-trill-oam-fm
> 
> Hi draft authors,
> After reviewing this draft, I think it's a very important framework draft and
> organized well. I support it with several comments below:
> 1. Several typos:
> 1) header format of section 8, section 9.2 are not correct. Similar problem
> also exists other place in the draft; [Tissa] Thanks and will fix them.
> 
> 2) Suggest to change the order between section 8 and section 9;
> 
> [Tissa] What do you mean by changing the order ? You mean to swap 8 and 9 ?
> If so I am not clear why. Section 8 is the explanation of general TLVs, Section 9
> is operation of Loopback message. Before explaining the mechanics of
> Loopback message we need explain the associated TLVs. Section 10 is Path
> trace message.
> 
> 3) TRILL OAM Specific TLVs names in section 8.4.2 are not consistent with the
> following draft; [Tissa] Thanks for noting that, will fix in the next edition.
> 
> 4) In section 9.2.1, "The TRILL OAM Version TLV" should be "The TRILL OAM
> Application Identifier TLV"?
> [Tissa] Thanks will fix it.
> 
> 2. In section 1, is reference to [TRLOAMFRM] ok because it's not a WG draft or
> RFC?
> [Tissa] Correct
> 
> 3. In section 12:
> 1) what's is the main goal of it? Detecting flow fault or path fault of
> multi-path (e.g. ECMP)?
> [Tissa] CCM js transmitted with a specific flow. Hence CCM detect per flow
> fault.
> 
> 2) What's the reason MEP transmits 4 CCM messages per each flow?
> [Tissa] 802.1ag section 20.1 Continuity Check Protocol, specifies loss of 3
> consecutive messages triggers a fault. Hence we have decided to transmit 4
> messages and loss of any 3 consecutive to detect the fault. This number 3 is
> hard coded in 802.1ag and we are proposing to use exactly the same. There is
> a reason for this hard coding. The reason is that in large networks
> maintaining consistent configuration is hard hence this parameter is kept
> constant. If one want to tune the CCM then can play with transmission
> intervals.
> 
> 3) The numbered CCM messages possibly arrive remote MEP out of order
> because the multi-path characteristics of TRILL; [Tissa] CCM path is governed
> by the flow entropy. So it is per flow behavior. If a flow arrive out of order
> means the data that it is mimicking is also out of order. Which in turn is a
> valid fault.  Multipathing cannot make data of a given flow out of order and
> should ensure in order delivery of packet per flow.
> 
> 4) Even if CCM messages can arrive remote MEP in order, the fault detecting
> scheme seems to be not correct totally and will give fault judgment. For
> example, when  MEP-B does not receive CCM messages of 3,4,5,6.
> 
> [Tissa] no it will not. Because, as explained above it is per flow that we are
> monitoring. So 1,2,3,4 are flow-1 and 5,6,7,8 are flow-2.  You have received
> 1,2 of flow-1 and 7,8 of flow-2 which qualifies as valid flow path.
> 
> B.R.
> Frank
> 
> > -----Original Message-----
> > From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Donald
> > Eastlake
> > Sent: Saturday, March 08, 2014 2:31 AM
> > To: trill@ietf.org
> > Subject: [trill] WG Last Call - draft-ietf-trill-oam-fm
> >
> > Hi,
> >
> > As announced at the TRILL WG meeting today, this starts a WG Last Call
> > on draft-ietf-trill-oam-fm-02.txt running through March 24th.
> >
> > Thanks,
> > Donald and Jon
> >
> > _______________________________________________
> > trill mailing list
> > trill@ietf.org
> > https://www.ietf.org/mailman/listinfo/trill
> 
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill