Re: [trill] Review of draft-ietf-trill-oam-framework-01

"Samer Salam (ssalam)" <> Tue, 07 May 2013 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 948B421F93AA for <>; Mon, 6 May 2013 18:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.391
X-Spam-Status: No, score=-9.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VDojHXRZFTlJ for <>; Mon, 6 May 2013 18:08:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A22F21F8825 for <>; Mon, 6 May 2013 18:08:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31111; q=dns/txt; s=iport; t=1367888927; x=1369098527; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=/yDJvysgB6EDk992T2hh8FNqWmBu6GFfLGO/BS+Yc0I=; b=hhW6Bg+exROI5CMrhm1tCE9Ld9HhhIXUPoE6UV1pqxSwtKfrzDxpK3rn 6uHFs9ur0xties9ADgYdnZ/MDPXCvAWQNL7S+VzUPqHVzIJaR5MLXQh3w XCd1Zpaa+ieYtiLegN49D5D5Hd0oULc+lKpl9LQp9p/T8bJdNvX+OSSOl w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.87,624,1363132800"; d="scan'208,217"; a="204148155"
Received: from ([]) by with ESMTP; 07 May 2013 01:08:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4718bwa026075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 May 2013 01:08:37 GMT
Received: from ([fe80::5404:b599:9f57:834b]) by ([]) with mapi id 14.02.0318.004; Mon, 6 May 2013 20:08:37 -0500
From: "Samer Salam (ssalam)" <>
To: Olen Stokes <>
Thread-Topic: [trill] Review of draft-ietf-trill-oam-framework-01
Thread-Index: Ac4wqFoDeYsGLCzuRWalcngnNaMvwQaBj90A
Date: Tue, 7 May 2013 01:08:36 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8F25FF8EA49D164EBE5F1B5AD33F3BC9123CC65Axmbalnx13ciscoc_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 May 2013 01:08:53 -0000

Hi Olen,

Thank you for the detailed review of the draft. Please find comment resolution responses inline…

From: Olen Stokes <<>>
Date: Wednesday, April 3, 2013 1:21 PM
To: "<>" <<>>
Subject: [trill] Review of draft-ietf-trill-oam-framework-01

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.

Fixed the text to match the diagram.

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?

The minimum required functionality is support for MIP and support for UP MEP on a virtual port. UP/DOWN MEPs on physical ports are optional.

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?

Text and the figure were updated to reflect FGL changes.

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.

The message formatting is identical albeit for the encoding of MA name. We have actually revisited the draft to follow the CFM terminology consistently.

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”?

Yes, fixed.

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?

This section was rewritten, would appreciate if you can please take a second look at it in case anything remained unclear.

7)  Section 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 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?

Indeed, the intent was the frame formats of Appendix C. We have fixed the text to reflect that.

9)  Section 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.

As mentioned above, we have updated the draft to consistently use 802.1Q (previously 802.1ag) terminology.

We will be sending the draft to the workgroup mailing list shortly.

Please let me know if you would like to discuss any of these items further.