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

From: Donald Eastlake <[email-masked]>
Date: Thu, 25 Oct 2012 17:35:37 -0400

Hi,

The TRILL WG Last Call on the TRILL OAM Requirements document ended
yesterday with a consensus for draft-ietf-trill-oam-req-02.txt. It
will be forwarded to the IESG for publication.

Thanks,
Donald and Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 26 Oct 2012 11:47:13 -0400

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.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 26 Oct 2012 12:14:20 -0400

> to have been picked up in the revised version. (I noted some of the

Let me clarify.  Most were addressed, But there were a couple of NITs
that apparently got missed, including ones I ran across in the revised
version. The substantive ones were addressed.

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 29 Oct 2012 21:09:07 -0400

Hi Thomas,

Thanks for the review.

> handled during the IETF LC, it might be better to just respin the

I don't see any problem is doing some editorial improvements. The
Shepherd review and PROTO statement have not yet been done and after
that the next stage is actually AD review...

> 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.

An IETF Operations Directorate review of this draft has been
explicitly requested. The draft would no doubt have gotten one
eventually but this may cause it to occur at an earlier stage.

> "we're done" and sending it to the IESG?

Earlier versions were reviewed by and I believe this draft was
provided early to the 802.1 participants who are working with the OAM
Design Team. In any case, this draft is intended to be the TRILL
requirements and should be generally independent of the technology
used -- for example independent of whether specific TRILL OAM
mechanisms more closely follow IEEE 802.1ag or MPLS OAM or the TRILL
native mechanisms that were being developed in the now expired
http://tools.ietf.org/id/draft-ietf-trill-rbridge-oam-02.txt draft or
other mechanisms.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]