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
- [trill] my comments on draft-ietf-trill-oam-frame… Romascanu, Dan (Dan)
- Re: [trill] my comments on draft-ietf-trill-oam-f… Donald Eastlake
- Re: [trill] my comments on draft-ietf-trill-oam-f… Samer Salam (ssalam)
- Re: [trill] my comments on draft-ietf-trill-oam-f… Samer Salam (ssalam)
- Re: [trill] my comments on draft-ietf-trill-oam-f… Romascanu, Dan (Dan)