Re: [trill] Review of draft-ietf-trill-oam-framework-01
Donald Eastlake <d3e3e3@gmail.com> Fri, 05 April 2013 02:06 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78FE21F9665 for <trill@ietfa.amsl.com>; Thu, 4 Apr 2013 19:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGIvujPdkdNe for <trill@ietfa.amsl.com>; Thu, 4 Apr 2013 19:06:56 -0700 (PDT)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1C21F9644 for <trill@ietf.org>; Thu, 4 Apr 2013 19:06:55 -0700 (PDT)
Received: by mail-ob0-f182.google.com with SMTP id ef5so3271198obb.13 for <trill@ietf.org>; Thu, 04 Apr 2013 19:06:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=BhM3TVwtSiATunsb3j6UVRRWDJsNDQQWqFdhBaH0Y48=; b=nHfKj0rxLxQvRb0y29JUeu7Tf68ZL7TaEu78Bgikaa5UEePS79soewXG3EOPN73d7k QJ1raCulqtvxAKkZLMk5xNCmaNrzol0re3CdyhfaSaYFUkg/TrKAsPpzfd2e31n8jAhf FIooL6hxoWAuwvqwHCCLZeBCcrWwOgL7WKPVXoitBNvX+y9YJe8k4K6Imdnyy/zzC1HI yrRwQpNuc7NA72z69e7fVkgi0b2n3dxx3DvxN+vXMWT7bUrql/vJTVYhJa2FlAcvZChE B/v28xAov3u1q9pFpDwdVmBRNFcGa8xXu3QlxOqOFMLh4bs7poljCenjSsVj0kxqyQ6W v+EA==
X-Received: by 10.60.60.227 with SMTP id k3mr6424377oer.97.1365127615608; Thu, 04 Apr 2013 19:06:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.28.131 with HTTP; Thu, 4 Apr 2013 19:06:35 -0700 (PDT)
In-Reply-To: <A3C4E51A53661B4EBEE7C5F5E6FCDEB502A172B83A1F@USEXCHANGE.corp.extremenetworks.com>
References: <A3C4E51A53661B4EBEE7C5F5E6FCDEB502A172B83A1F@USEXCHANGE.corp.extremenetworks.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 04 Apr 2013 22:06:35 -0400
Message-ID: <CAF4+nEFbn9K364GDFtrqLJ6iyeb4_=M78BNsPxEBOMUZYpASJQ@mail.gmail.com>
To: Olen Stokes <ostokes@extremenetworks.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 05 Apr 2013 02:06:56 -0000
Hi Olen, Thanks for promptly posting these comments. Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Apr 3, 2013 at 4:21 PM, Olen Stokes <ostokes@extremenetworks.com> wrote: > Based on a review of the subject document, please consider the following > comments: > > > > 1) Section 2.6 states that “a CFM MEP resides in the "802.1Q Port VLAN > Processing" block” of Figure 2. I was not able to find a block with that > title in Figure 2. > > > > 2) Section 2.6 states that “A TRILL OAM solution that conforms to this > framework” MAY support UP MEP’s and MAY support DOWN MEP’s on TRILL physical > ports. I was unclear about the implications of these statements. Does that > imply that a solution could be acceptable even though it does not support > either UP or DOWN MEP’s? > > > > 3) Section 3.1 at the top of Page 16 states, “The TRILL Header is as > specified in [RFC6325]”. Should this paragraph include some discussion or > reference to the TRILL Header as specified in the Fine Grained Labeling > (FGL) document, especially since the FGL document “changes the description > of the TRILL Header” in its Section 2.2? > > > > 4) Section 3.3 states, “The use of [802.1Q] CFM encoding format for the OAM > Message channel is one possible choice.” Given the amount of Y.1731 > terminology used in this document, it might be helpful to at least make some > statement about the possibility of using Y.1731 formatting. I understand > that the formats are compatible, but there are some differences. > > > > 5) Section 3.3 references [TRILL-OAM] which is listed as > “draft-tissa-trill-8021ag”. This document is expired. Has it been replaced > by “draft-tissa-trill-oam-fm-01.txt”? > > > > 6) Section 3.4 suggests “using a reserved MAC address as the inner MAC SA” > to identify a TRILL OAM packet. It is unclear to me how this is more > backwards compatible than using previously unused fields or bits in the > TRILL Header as suggested in the preceding paragraph. Is not the inner MAC > SA used in some configurations for hashing at hops with equal-cost paths? > > > > 7) Section 4.1.2.2 describes Reverse Defect Indication (RDI). Given that > Section 4.1.1 states that fault detection must be able to exercise each > equal-cost path individually, Section 4.1.2.2 should probably state that RDI > must be able to identify on which equal-cost path the failure was detected. > > > > 8) Section 4.2.1 discusses carrying “test patterns as defined in > [RFC2544].” RFC 2544 is a substantial document but it does not contain the > word “pattern”. Is this a reference to the frame formats in Appendix C or > to some other section of the RFC? > > > > 9) Section 4.2.1.2 discusses an un-pruned tree and a campus wide diagnostic > VLAN. A campus wide diagnostic FGL is probably also required. > > > > 10) Section 4.2.2 discusses fault isolation. It would be helpful to include > a statement that fault isolation has to work for both known unicast and > multi-destination packets. > > > > As a general comment, Section 1.2 states that the document “leverages > concepts and draws upon elements defined and/or used” in multiple existing > OAM standards including 802.1ag CFM and Y.1731. The document contains a > mixture of terms from these two standards. For example, the Y.1731 term > Maintenance Entity Group (MEG) is used as opposed to the 802.1ag term > Maintenance Association (MA). However, the 802.1ag term Maintenance Point > (MP) is used as opposed to the Y.1731 term Maintenance Entity (ME). It does > not appear to affect the technical content but it is unclear why the > terminology is mixed. Some statement about the method used to determine > which terms to use might be helpful. > > > > Please let me know if you would like to discuss any of these items further. > > > > Cheers, > > Olen > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill >
- [trill] Review of draft-ietf-trill-oam-framework-… Olen Stokes
- Re: [trill] Review of draft-ietf-trill-oam-framew… Donald Eastlake
- Re: [trill] Review of draft-ietf-trill-oam-framew… Samer Salam (ssalam)