Re: [trill] my comments on draft-ietf-trill-oam-framework

"Samer Salam (ssalam)" <ssalam@cisco.com> Wed, 17 April 2013 17:37 UTC

Return-Path: <ssalam@cisco.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 9418221F871C for <trill@ietfa.amsl.com>; Wed, 17 Apr 2013 10:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Q70BE9mxaHUp for <trill@ietfa.amsl.com>; Wed, 17 Apr 2013 10:37:56 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0D821F8652 for <trill@ietf.org>; Wed, 17 Apr 2013 10:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7723; q=dns/txt; s=iport; t=1366220276; x=1367429876; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=lYEimEQ7PMa/+HbpqjHJk0z+IgDfUh0FBjehYjDQKOc=; b=M1WmZn/va8UacPwSzutgrPZWVadze4IsQR47sL3QHwsdMnA/tMuUw4FK hQvaeesEiAV7r/NtCwQ78ULXDEnTn3ESZ2RwTMnvWFFflCk7J5xN1OVw/ BgswI0cl5esBpiRpF22mrFaqc7GQrFbj3VaUZSedLjsDidRs1HHxzB9Ie k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFAO/cblGtJXG8/2dsb2JhbABGCoJlITbARIEEFnSCIQEEAQEBNzQEGQEIIhQ3CyUBAQQBEggTh3kBC71VBI1egQs4gmVhA5M5lGGDC4Io
X-IronPort-AV: E=Sophos;i="4.87,495,1363132800"; d="scan'208";a="199873276"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 17 Apr 2013 17:37:55 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3HHbtK6014492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 17:37:55 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 12:37:55 -0500
From: "Samer Salam (ssalam)" <ssalam@cisco.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, TRILL Working Group <trill@ietf.org>
Thread-Topic: [trill] my comments on draft-ietf-trill-oam-framework
Thread-Index: Ac4xEkkxNdzOrNdAThmijtqtgZEQwgKbzx8A
Date: Wed, 17 Apr 2013 17:37:54 +0000
Message-ID: <8F25FF8EA49D164EBE5F1B5AD33F3BC9123A0CE2@xmb-aln-x13.cisco.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C1543@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [161.44.210.96]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7FC8254F651CA64C975E8E97B0CD2735@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [trill] my comments on draft-ietf-trill-oam-framework
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: Wed, 17 Apr 2013 17:37:57 -0000

Hi Dan,

Thank you for your comments, we will incorporate them into the updated
draft.

Best Regards,
Samer

On 13-04-04 1:56 AM, "Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:

>Hi,
>
>Here are my comments on draft-ietf-trill-oam-framework-01.txt
>
>I have divided them in Technical and Editorial.
>
>
>Technical
>
>T1. The references are broken in many ways. Many references in the text
>are not included in the References sections - runing id-nits shows this
>immediately. Listed references point to documents that do not exist
>[TRILL-OAM], [TRILL-IP].
>
>T2. I have mixed feelings about the usage of RFC 2119 capitalized
>keywords in this document. My preference would be to drop them
>completely, especially as the document is targeting Informational status.
>If they stay, we need to carefully review the usage, right now it's quite
>inconsistent. 
>
>T3. The document does not include a section on operational and
>manageability considerations. I believe that this is necessary, and this
>section should include as a minimum:
>- what parameters need to be configured on Rbridges in order to activate
>TRILL OAM - activation of specific OAM functions, periodicity of OAM
>messages, activation of synthetic traffic (periodic or on demand)
>- how are these parameters configured? Are there recommended default
>values? 
>- how are results of Performance Management used or retrieved?
>
>T4. Several terms are used according to the terminology defined in RFC
>6905 - Section, Flow, Connectivity, Continuity Indication, etc. I suggest
>to mention this in Section 1.2
>
>T5. Are the references to L2VPN and MPLS-TP (and the respective [RFC6136]
>and [RFC6371]) in Section 1.2 needed at all? I do not see these
>technologies mentioned in any other part of the document, and if there is
>no relevant relationship with the OAM functions on these layers I would
>suggest to drop these.
>
>T6. In 2.4 we have an example why using 2119 capitalized keywords is
>problematic:
>
>> When considering multi-domain scenarios, the following
>   rules must be followed: TRILL OAM domains MUST NOT overlap, but MUST
>   either be disjoint or nest to form a hierarchy (i.e. a higher
>   Maintenance Domain MAY completely engulf a lower Domain).
>
>If I was to chose, I would prefer not to use capitalization, or use
>capitalization only for the first 'must' which is not capitalized in the
>text. 'MUST either ...' is a strange combination. One may argue that
>nesting is a form of overlapping, and actually 'MUST not overlap' is
>should rather be 'MUST not partially intersect'.
>
>T.7 In Section 3.1:
>
>> Additionally
>   methods must be provided to prevent OAM packets from being
>   transmitted out as native frames.
>
>If capitalized RFC 2119 keywords are to be kept, this 'must' must be a
>'MUST' (because of the critical impact on the bits on wire)
>
>T.8 In section 3.2:
>
>>  When running OAM functions over Test Flows, the TRILL OAM should
>   provide a mechanism for discovering the flow entropy parameters by
>   querying the RBridges dynamically.
>
>I am wondering why this is a 'should' and not a 'must'. Are there any
>exception cases? 
>
>T.9 Section 3.4: 
>
>>  RBridges must be able to identify OAM messages that are destined to
>   them, either individually or as a group, so as to properly process
>   those messages.
>
>OK - so a method must be in place.
>
>   It may be possible to use a combination of one of the unused fields
>   or bits in the TRILL Header and the OAM EtherType to identify TRILL
>   OAM messages. 
>
>' one of the unused fields or bits in the TRILL Header' - which ones? Are
>we talking about an update to RFC 6395? Where is this defined?
>
>Is the 'and' between the TRILL header combinations and the OAM EtherType
>really an 'and' or rather an 'or'? 'OAM EtherType' is rather 'TRILL OAM
>EtherType'? 
>
>   [RFC6325] does not specify any method of identifying OAM messages.
>   Hence, for backwards compatibility reasons, TRILL OAM solutions must
>   provide methods to identify OAM messages through the use of well-
>   known patterns in the Flow Entropy field; for e.g., by using a
>   reserved MAC address as the inner MAC SA.
>
>Is this an alternate method to the ones described in the previous
>paragraph? Then, the 'must' is probably rather a 'may' or should'. What '
>reserved MAC address' are we talking about? Is this something that we
>should ask from the IEEE RAC? Where is this specified?
>
>T.10 Section 4.1.1 - What does 'Period mis-configuration' mean? Is this
>about the periodicity of the OAM messages? If so this defect is about OAM
>configuration, not about continuity check. If it's something different,
>please explain or provide a reference.
>
>T.11 Section 4.2: 
>
>>  On-demand fault management functions are initiated manually by the
>   network operator and continue for a time bound period.
>
>The last part of the statement is not always true, as some fault
>management functions may be one-time actions or tests.
>
>T.12 Section 5. - Performance Management - I am not thrilled about this
>section at all. Note that RFC 6905 talks about Performance Monitoring
>(not Management) and it's not a mandatory function. Terminology aside, I
>dislike generating synthetic traffic in order to measure packet loss -
>how much traffic? Limiting this seems mandatory. Who compares what was
>sent with what was received?  5.2 talks about hardware-based
>time-stamping to measure Packet Delay. This implies some kind of clocks
>synchronization between RBridges. What are the requirements?
>
>T.13 The Security Considerations section should be more explicit on what
>'exploitation of the OAM message channel' means. Specifically the threats
>related to overloading the network and the Rbridges with OAM messages
>should be mentioned, as well as the impact of interrupting the OAM
>services. 
>
> 
>
>Editorial
>
>E1. In Section 1: 
>
>>  Some
>   characteristics of a TRILL network that are different from Ethernet
>   bridging ...
>
>s/Ethernet bridging/IEEE 802.1 bridging/
>
>E2. Check for completeness of the acronyms list in section 1.1. For
>example ECMP is used a few times in the document, but not listed here and
>never expanded. 
>
>E3. In several places (2.1.3 is the first) I found 'For e.g.,'. I believe
>that this is a pleonasm, either use 'For example', or just e.g.
>
>E4. In section 2.2: s/TRILL OAM processing can be modeled as a
>layer/TRILL OAM processing can be represented as a layer/
>
>E5. In Section 2.3:
>
>>  Network OAM mechanisms provide fault and performance management
>   functions in the context of a representative 'test' VLAN or fine-
>   grained label [TRILL-FGL].
> 
>What does 'representative' mean here?
>
>E6. 'faults in connectivity or performance' - 'connectivity faults and
>performance degradation' is probably better
>
>E7. In Section 2.6:
>
>> MEPs are the active components of TRILL OAM: MEPs source TRILL OAM
>   messages proactively or on-demand based on operator invocation.
>
>The usage of the term 'proactively' seems to me to be incorrect. I would
>rather use 'periodically'. Also s/operator invocation/operator
>configuration actions/
>
>
>
>E8. In Section 2.6:
>
>> - MUST support the UP MEP function on a TRILL virtual port (to
>     support OAM functions on Sections)
>
>I would add for clarity inside the brackets '... as defined in 'rfc6905'
>
>Regards,
>
>Dan
>
>_______________________________________________
>trill mailing list
>trill@ietf.org
>https://www.ietf.org/mailman/listinfo/trill