[RTG-DIR] rtg dir review of draft-ietf-l2tpext-sbfd-discriminator

Loa Andersson <loa@pi.nu> Fri, 18 December 2015 14:22 UTC

Return-Path: <loa@pi.nu>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94111B365E; Fri, 18 Dec 2015 06:22:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-OJv0hQ1jsD; Fri, 18 Dec 2015 06:22:18 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0731B3658; Fri, 18 Dec 2015 06:22:14 -0800 (PST)
Received: from [192.168.1.13] (unknown [112.205.86.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 61DED18013CB; Fri, 18 Dec 2015 15:22:11 +0100 (CET)
From: Loa Andersson <loa@pi.nu>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, rtg-dir@ietf.org, draft-ietf-l2tpext-sbfd-discriminator@ietf.org, l2tpext@ietf.org
Message-ID: <56741688.9080104@pi.nu>
Date: Fri, 18 Dec 2015 22:22:00 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/zjwa82CxTfdQpsX-FhKWh7wSBEc>
Subject: [RTG-DIR] rtg dir review of draft-ietf-l2tpext-sbfd-discriminator
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2015 14:22:21 -0000

  Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see ​ 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-l2tpext-sbfd-discriminator-01.txt
Reviewer: Loa Andersson
Review Date: 2015-12-18
IETF LC End Date: date-if-known
Intended Status: Proposed Standard (ID says Standards track)

Summary:

     I have some minor concerns about this document that I think should 
be resolved before publication.

Comments:

      I have considerable problems reading the draft, first it does not
really follow RFC 7322 in some important details, also the format figure
(as I understand it) is misleading. The document need a facelift.



Major Issues:

     "No major issues found."

Minor Issues:

     Even though the nit-picking below is pretty massive, it is purely
editorial and should be fixed before going to IETF Last Call. I have
no real concerns about the technical content

Abstract:
---------
     I used often "my immediate manager" as a reference and said that
the abstract should give her/him a good idea about what the draft is
about. I don't think the abstract meet that standard. Could you please
flesh out.

     RFC 7322 says that "Similarly, the Abstract should be complete
in itself.  It will appear in isolation in publication announcements
and in the online index of RFCs." If I encounter this and is not up to
speed on l2tp and bfd, this does not give a good idea what it is about.

Abbreviations

RFC 7322 says:
    Abbreviations should be expanded in document titles and upon first
    use in the document.  The full expansion of the text should be
    followed by the abbreviation itself in parentheses.  The exception is
    an abbreviation that is so common that the readership of RFCs can be
    expected to recognize it immediately; examples include (but are not
    limited to) TCP, IP, SNMP, and HTTP.  The online list of
    abbreviations [ABBR] provides guidance.  Some cases are marginal, and
    the RFC Editor will make the final judgment, weighing obscurity
    against complexity.

The abbreviations are not expanded in title, abstract, and some other
places, nor are they "well-known".

Examples
AVP - the RFC Editor abbreviation list gives two expansions, since this
is l2tp I come to the conclusion that this is "attribute-value pair" and
not the wellknow "Audio-Visual Profile (AVP)"

S-BFD - BFD is not well-known, and S-BFD is not even in the RFC Editors
abbreviations list.

L2TPv3 - L2TP or L2TPv3 are not well-know. There is no RFC that does
not expand the abbreviation in the title.

ICRQ, ICRP, OCRQ, and OCRP are sued but not expanded, the pointer to 
where to find the expansions (RFC 3931) are nit give until the third
time the quartet is mentioned

LCCE - used but not expanded. nor well-known.
The RFC Editor abbreviations has two expansions
LCCE       - Logical Cluster Computing Environment (LCCE) or
            - L2TP Control Connection Endpoint (RFCs 3931 and 4719)
Since this is is L2TP context, it is the latter that is correct, but
since we have an ambiguity we need to expand.

Section 2

I have a problem parsing this sentence:

    This AVP is exchanged during session negotiation (ICRQ, ICRP, OCRQ,
    OCRP).

Do you mean to say

    The "S-BFD Target Discriminator ID" AVP is exchanged using the ICRQ,
    ICRP, OCRQ, and OCRP control messages during session negotiations.

Section 2.1
    There is a TBD in the first sentence of this paragraph. While I
    agree that TDB is "well-know" I prefer using [TBA by IANA],
    where TBA stands for To Be Assigned.
    If you change this you also need to change in the IANA section.

Excuse me if I don't understand this figure

                                                      No. of octets
                  +-----------------------------+
                  | Discriminator Value(s)      |     4/Discriminator
                  :                             :
                  +-----------------------------+

First I think you say that a Discriminator is 4 octets
Second there can be a variable number of discriminators per attribute
value field
The box in your figure seems to 29 bits wide, this is unorthodox.


                   0       1       2       3
                   01234567012345670123456701234567
                  +-----------------------------+
                  | Discriminator Value(s)      |
                  :                             :
                  +-----------------------------+

Is this what you mean?

                   0       1       2       3
                   01234567012345670123456701234567
                  +--------------------------------+
                  | Discriminator Value (1)        |
                  +--------------------------------+
                  :                                :
                  +--------------------------------+
                  | Discriminator Value (n-1)      |
                  +--------------------------------+
                  | Discriminator Value (n)        |
                  +--------------------------------+

Discriminator - a 4 octet value

IANA consideration

      There is a practice - which I disagree with - to assume that IANA
and readers know where to the registries. Please point it out so no
mistakes are possible.

OLD TEXT
This number space is managed by IANA as per [RFC3438].

NEW TEXT
IANA maintain a sub-registry "Message Type AVP (Attribute Type 0)
Values" in the "Control Message Attribute Value Pairs" as per
[RFC3438]. IANA is requested to assign the first free value from this
sub-registry as the Message typ AVP for "S-BFD Discriminators".


Nits:

The nits tool does only give us the date warning.

/Loa



-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64