[mpls] AD review of draft-ietf-mpls-ldp-ip-pw-capability

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 17 October 2013 13:18 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6545911E81B5 for <mpls@ietfa.amsl.com>; Thu, 17 Oct 2013 06:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599]
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 RU1ekR5stYZg for <mpls@ietfa.amsl.com>; Thu, 17 Oct 2013 06:18:22 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 643F911E818F for <mpls@ietf.org>; Thu, 17 Oct 2013 06:18:22 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9HDIKYE031089; Thu, 17 Oct 2013 14:18:20 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r9HDIJCq031079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Oct 2013 14:18:20 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org
Date: Thu, 17 Oct 2013 14:18:18 +0100
Message-ID: <02fe01cecb3b$59333440$0b999cc0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac7LO08u/cU1gZSjRe6Id4NFyYN+9A==
Content-Language: en-gb
Cc: mpls@ietf.org
Subject: [mpls] AD review of draft-ietf-mpls-ldp-ip-pw-capability
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2013 13:18:39 -0000

Hello authors of draft-ietf-mpls-ldp-ip-pw-capability,

I have done my usual AD review of your draft having received the
publication request. The purpose of my review is to remove any 
issues that I can find before the document reaches IETF last call
and IESG evaluation.

Technically, this is a fine piece of work, but I'm afraid I have a
few of editorial issues. I hope they will be quick for you to fix so
we can move ahead with the IETF last call.

Please feel free to discuss/reject any of my requests.

Thanks for the work,
Adrian

===

IPoMPLS is not a common term. Fortunately you do define it quite early
in the document, but not until after you have used it a couple of times.
Could you please at least expand the acronym in the Abstract and 
Introduction, and maybe give a forward pointer to the definition from 
the Introduction.

But be really careful! The term "IP Label Switching" seems to be hardly
used anywhere (says Google) except:
- in this I-D
- in IOS to mean "hop-by-hop label switching" (about which I am also
  none the wiser :-)
- in old material as a synonym for MPLS.
So your definition of IPoMPLS in Section 2 doesn't actually tell us 
what it is.

---

You need to take some care with acronyms on first use. You can check at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt to see
which are well known and don't need to be expanded.

I see
P2P
PW
LSR
P2MP
mLDP
FEC
L2VPN
PE

---

Are you sure you don't want IANA to manage a registry for

   State: Defines the type of application state (to be controlled).  
      The value of this field is defined as follows: 
       1: IPv4 Label switching 
       2: IPv6 Label switching 
       3: P2P PW FEC128 signaling 
       4: P2P PW FEC129 signaling 
      0, 5-15: Reserved. 

What does "Reserved" mean?

---

It seems (to me) odd that you require four SEC elements to disallow 
all four listed states. I would have thought bit flags would be more
efficient with 1 disallows and 0 allows.

But since this is a case of "I would not have done it this way", you
do not need to make this change on my account provided the WG is OK
with what you have here.