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
>