Re: [trill] Consensus Call: draft-ietf-trill-oam-req

Thomas Narten <narten@us.ibm.com> Fri, 26 October 2012 15:47 UTC

Return-Path: <narten@us.ibm.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 049F421F862B for <trill@ietfa.amsl.com>; Fri, 26 Oct 2012 08:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao+XCOzCeb2M for <trill@ietfa.amsl.com>; Fri, 26 Oct 2012 08:47:31 -0700 (PDT)
Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id BE40021F8620 for <trill@ietf.org>; Fri, 26 Oct 2012 08:47:30 -0700 (PDT)
Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <trill@ietf.org> from <narten@us.ibm.com>; Fri, 26 Oct 2012 11:47:27 -0400
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 26 Oct 2012 11:47:26 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 8089EC90062 for <trill@ietf.org>; Fri, 26 Oct 2012 11:47:25 -0400 (EDT)
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9QFlOY5240978 for <trill@ietf.org>; Fri, 26 Oct 2012 11:47:24 -0400
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9QFlKKl019121 for <trill@ietf.org>; Fri, 26 Oct 2012 09:47:23 -0600
Received: from cichlid.raleigh.ibm.com ([9.80.28.55]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q9QFlFPU018566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2012 09:47:17 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q9QFlD4f021574; Fri, 26 Oct 2012 11:47:13 -0400
Message-Id: <201210261547.q9QFlD4f021574@cichlid.raleigh.ibm.com>
To: Donald Eastlake <d3e3e3@gmail.com>
In-reply-to: <CAF4+nEE1vn+oRi9w4Ra0EjQsFrdJu4TO605Vu0=KAyNuio8N3A@mail.gmail.com>
References: <CAF4+nEE1vn+oRi9w4Ra0EjQsFrdJu4TO605Vu0=KAyNuio8N3A@mail.gmail.com>
Comments: In-reply-to Donald Eastlake <d3e3e3@gmail.com> message dated "Thu, 25 Oct 2012 17:35:37 -0400."
Date: Fri, 26 Oct 2012 11:47:13 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12102615-5806-0000-0000-00001B114E67
Cc: trill@ietf.org
Subject: Re: [trill] Consensus Call: draft-ietf-trill-oam-req
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, 26 Oct 2012 15:47:32 -0000

Sorry to chime in late, but I did another careful review of this
document.

At a high-level, I think it's mostly ready to go. I did find a few
things (below) that I think need addressing. While they could be
handled during the IETF LC, it might be better to just respin the
document first.

I also note that Don Eastlake had a number of comments that don't seem
to have been picked up in the revised version. (I noted some of the
same editorial issues.)

The one concern I have is whether this document has gotten enough and
the right kind of review. 4 of the 7 "support" (5 of 8 counting mine!)
come from the main contributers of the document. I'd feel better if
this document got more reviews from those who haven't been closely
involved in the work.

Also, given our desire to coordinate with the IEEE 802.1 on OAM,
shouldn't we act to get some reviews from that side before saying
"we're done" and sending it to the IESG?

Specific comments below.

Thomas

2012-10-26 rereview (WGLC) of  -02

   terminologies defined in other OAM standards such as [8021ag],
   [RFC5860]. This document does not attempt to redefine the terms and

insert "and" between references.   

   or unspecified. Unspecified means that messages used for
   connectivity verification take whatever that path the RBs happen to
   select.

s/that path/path/

   OAM frames, utilized for connectivity verification, continuity
   checks, performance measurements, etc., will by default take
   whatever the path TRILL chooses based on the current topology and

s/the path/path/

   RBridges MUST have the ability to identify OAM frames destined for
   them or which require processing by the OAM plane from normal data
   frames.

Don't understand the implications of this. What does this requirement
actually mean?

   TRILL OAM frames MUST NOT be forwarded out as native frames on end
   station service enabled ports.

what is an "end station service enabled port"? Where is this defined?
Maybe reword to something like:

   TRILL OAM frames MUST remain within a TRILL campus and MUST NOT be
   egressed from a TRILL network as native frames.


   OAM MUST have ability to include all Ethernet traffic types carried
   by TRILL, including both IP and non-IP traffic.

something better?

   From an arbitrary RBridge RB1, OAM MUST have the ability to verify
   connectivity to any other RBridge RB2 for a specific flow via the
   path associated with the specified flow

Missing "."

   OAM MUST have the ability to verify connectivity, from an arbitrary
   RBridge RB1, to either to a specific set of RBridges or all member
   RBridges, for a specified multicast tree and for a specified flow.

s/to either to/to either/

   OAM SHOULD NOT require extensions to the TRILL header. OAM MAY be
   required to provide the ability to specify a desired response mode
   for a specific OAM message. The desired response mode can be either
   in-band, out-of band or none.

The above is a bit ironic, as the thinking as of Vancouver was to make
use of a bit in the extension header. Take it out?

   In this document, term loss of a packet is used as defined in
   [RFC2680] (see Section 2.4 of RFC2680).

s/term/the term/

   NOTE: The term simulated flow below indicates a flow that is
   generated by an RBRidge RB1 for OAM purposes. The fields of the
   simulated flow may or may not be identical to the actual data.
   However, simulated flow is required to follow the intended path.

This might be better moved to the terminology section (it's in 4.6.1)

Also, better wording:

   The term simulated flow refers to a sequence of OAM-generated
   packets designed to follow a specific path.  The fields of the
   packets in the simulated flow may or may not be identical to the
   fields of data packets of an actual flow being simulated. However,
   the purpose of the simulated flow is to have OAM packets of the
   simulated flow follow a specific intended path.

from 4.6.2:

   Two-way delay is also referred to as Round Trip Delay is defined

s/Delay/Delay and/


Also:

   Two-way delay is also referred to as Round Trip Delay is defined
   similar to [RFC2681]; i.e. the time elapsed from the start of
   transmission of the first bit of a packet by an RBridge until the
   reception of the last bit of the packet by the same RBridge.

This isn't quite right. The text "reception of the last bit of the
packet" is ambiguious.

I.e., for "ping", RTT involves a request and response packet, i.e.,
the response packet is not the same as the request packet. RFC 2681
(cited) also notes that distinction. I.e, the above seems to imply
that RTT involves the  exact same packet being returned to the sender,
which we can't do in general with TRILL.

Better:

   Two-way delay is also referred to as Round Trip Delay and is
   defined similar to [RFC2681]; i.e. the time elapsed from the start
   of transmission of the first bit of a packet from RB1, receipt of
   the packet at RB2, RB2 immediately sending a packet back to
   RB1, and RB1 receiving of the last bit of that packet.

>From 4.6.2:

   OAM SHOULD provide functions to measure two-way delay between two
   RBridges for a specified flow over a specific section.

How can this be implemented? Flows (by definition) are
unidirectional. I.e., given an end-to-end flow, the entropy fields in
one direction will be different than those in the opposite direction
(e.g., the src/dst addresses will be swapped for starters). This means
that we can set the flow for the direction from RB1 to RB2, but what
flow should be used for the return path?

4.10. Defect Indications

This entire section has sentence that start off "OAM implementations
that provide Defect Indication", which implies to me that everything
in is section is optional. Is that really the case? Also, this section
talks about "Implementations". This docuemnt shouldn't be saying what
implementations should/should not do, but should be talking about what
facilities OAM needs to provide.

I don't have any obvious rewording suggestions,  but do not think the
current wording is what we want. Any suggestions?

   OAM implementations that provide Defect Indication MUST provide
   methods to selectively enable or disable Defect Detection per defect
   type.

   OAM implementations that provide Defect Indication MUST provide
   methods to configure Defect Detection thresholds per different types
   of defects.

I'm wondering why the above are MUSTs. SHOULD seems more
appropriate, especially since "OAM implementations that provide"
already implies the requirement is optional.