Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

"Susan Hares" <> Fri, 30 May 2014 02:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37B4F1A07B0 for <>; Thu, 29 May 2014 19:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vSt1rgq6YS2M for <>; Thu, 29 May 2014 19:32:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 63AF21A029A for <>; Thu, 29 May 2014 19:32:17 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Tal Mizrahi' <>, 'Donald Eastlake' <>
References: <005301cf7a01$8f2ed200$ad8c7600$> <> <000301cf7a5f$9ba0eb50$d2e2c1f0$> <>
In-Reply-To: <>
Date: Thu, 29 May 2014 22:32:11 -0400
Message-ID: <00f701cf7baf$5cf27300$16d75900$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHSZ7EyT6EveJweaWumkLBv9lSqqQHzqYJbAxwSyJUAyIpURJsjyVyA
Content-Language: en-us
Cc:, 'Jon Hudson' <>,
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 May 2014 02:32:19 -0000


This looks good to me.  I have adjusted the shepherds report and Donald can
forward this to the AD/IESG.


-----Original Message-----
From: Tal Mizrahi [] 
Sent: Thursday, May 29, 2014 2:02 PM
To: Susan Hares; 'Donald Eastlake'
Cc:;; 'Jon Hudson'
Subject: RE: [trill] Shepherd's review of draft-ietf-trill-loss-delay


Thanks for the comments.
I posted an updated draft that addresses these comments.


-----Original Message-----
From: trill [] On Behalf Of Susan Hares
Sent: Wednesday, May 28, 2014 1:29 PM
To: 'Donald Eastlake'
Cc:;; 'Jon Hudson'
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay


I agree that the normative reference [OAM-FRAMEWK] (now [RFC7174]) can be
changed to an informative reference, which would avoid the down reference.

On the textual "4.4.1 ", if it is easier - let the RFC Editor fix the final
form.  I will note the RFC editor should watch for it, and remove the
editorial comment for the authors. 

On the IANA suggestion,  I agree that IANA should not have control over the
registries that IEEE 802.1 has. The question is whether IANA should track
the non-IETF specifications that IETF drafts includes.  Unless someone
objects, I will remove this comment from the shepherds report. 

I'll see if anyone else has comments on the shepherds report today until 3pm
ET, and then change it. 


-----Original Message-----
From: trill [] On Behalf Of Donald Eastlake
Sent: Tuesday, May 27, 2014 11:40 PM
To: Susan Hares
Cc:; Jon Hudson;
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

Hi Sue,

Thanks for the Shepherd review.

On Tue, May 27, 2014 at 7:15 PM, Susan Hares <> wrote:
> Authors and TRILL WG:
> I submit for the authors and WG's review attached review of the 
> draft-ietf-trill-loss-delay-03.txt
> Sue Hares
> -----
> Document Quality
> The written text of this document is high.  The performance monitoring 
> issues clearly specified with clear descriptions of the mechanisms.
>  This document is a pleasure to read with only 3 editorial issues 
> mentioned Below, and one IANA suggestion.


>  The document has been co-authors by two groups implementing the  code 
> for deployment (Cisco and Huawei).  The careful attention to
> operational issues have shows in this draft.   No specific announcement
> of the release date for  these TRILL PM implementations has been made.  
> An implementation survey planned for June so a better understanding of 
> the deployments may align with the IESG review.
>  Other vendors have indicated consideration of the PM specification.
> Required Editorial Fixes [May be deleted if authors revise] =====
> draft-to-RFC updated needed:
> 1) Outdated reference: draft-ietf-trill-oam-framework has been
>      published as RFC 7174
> 2) Outdated reference: draft-ietf-trill-fine-labeling has been 
> published as RFC 7172

Yes, these need to be updated.

> -------
> downref: Normative reference to informational draft
>      draft-ietf-trill-oam-framework (ref. 'OAM-FRAMEWK')
> As a shepherd, I find this to be correct technically.  However, WG 
> chairs/AD should review this down ref.

I'm not sure. There is a lot of interesting background in the framework
document, but do you actually have to look at it to implement this draft?
The closest I can find to that is the following text in the draft:

      This document does not define procedures for packet loss
      computation based on counting user data. For further details see

This sort of looke like a normative reference but really, I think it should
be changed to something like

      This document does not define procedures for packet loss
      computation based on counting user data for the reasons given in
      Section 5.1 of [RFC7174].

So, unless I'm missing something, I think the normative reference to
[OAM-FRAMEWK] (now [RFC7174]) can be changed to an informative reference,
which would avoid the down reference.

> Suggested Technical changes
> [pages 24-25: Is the reserved field zero? If so, please indicate.
> If not, please indicate that it is unspecified.
> Editorial:
> "4.1.1 ,"  to "4.4.1,"
> [this seems to be an artifact of the word processing]

I'm slightly confused. There seem to be two occurrences of "4.1.1" but
neither looks like that and there seem to be zero occurrences of "4.4.1"...
Near the beginning of Section 4.1.1 there is a "3.2.1.  ,"
(with two spaces).  Typically I think that sort of thing is due to weirdness
with MS Word adding a space. It may be hard to fix if the original is in
that form, but the RFC Editor can clear such stuff up.

> -----
> IANA suggestion:
> It may be worth considering if IANA should keep a record assignments 
> of the
> Y.1731 defined in 6.4.  This will be useful if there is ISO/IETF 
> collaboration discussion.

IANA registries for the OpCodes and TLV Types values that are available for
IETF assignment are being set up by draft-eastlake-iana-cfm-considerations
which is currently in IESG ballot. However, this draft doesn't need to
allocat any additional values. IEEE 802.1 is in charge of these code points
and has allocated blocks to ITU-T, for Y.1731, and to IETF for TRILL and
other IETF uses.  I'm not sure that IANA having informative duplicative of
code points in this space that are not on IANA control is such a good idea.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> Sue Hares

trill mailing list

trill mailing list