[mpls] Review of draft-rosen-mpls-rfc3107bis

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 02 August 2016 16:30 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 EC80712D7F8; Tue, 2 Aug 2016 09:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 NP5mcmfWVkXh; Tue, 2 Aug 2016 09:30:44 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A202B12D7B5; Tue, 2 Aug 2016 09:30:39 -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 u72GUaPK022644; Tue, 2 Aug 2016 17:30:36 +0100
Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u72GUZD4022638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2016 17:30:36 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-rosen-mpls-rfc3107bis.all@ietf.org>, <mpls-chairs@ietf.org>
Date: Tue, 2 Aug 2016 17:30:33 +0100
Message-ID: <041801d1ecdb$317d1910$94774b30$@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: AdHs2x9YnjkQGGhQRauvGXHQ1y3S/w==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22490.000
X-TM-AS-Result: No--5.685-10.0-31-10
X-imss-scan-details: No--5.685-10.0-31-10
X-TMASE-MatchedRID: nYDoSt+wnM+6ZDHWKjqh6W/CU2X9JBM7GSqdEmeD/nU2EmUJIG0ZhSHJ 1yg4Z6oQWkXeWXJ95OdItk1kJcwZlPw6RJrswLb72MZGQuKc8Uhu/Xr6CKXiN6T/Ovsh3unZ5sZ TwYHfBM7nv2asX1kk14iH18/o5EiwAMFp5W5WHQJVnniKh7YTC2q+82wYIfAL31GU/N5W5BCBmd P/ge92IDPWvTFiHi7AKYMyBIAmGGX2ckw6NiGelMWUKBjERoYTukAkwrs34lWNTnqOMBIJ4b1ou XsdIwnSiO6l2XXUgR3sOHIqpBslB5Ur57gGJJl5syNb+yeIRAoxmbT6wQT2aznKpbGL4ChV9BQF Wu9qPYZbo8t2lZn/uw33Yw3ZuJJ70NXTByOPgI1VTfJWlqPdDPBkYT/50xzWl3JzVGvmhUXK6QT LokP+5h5QbKQv+Ib0dA6sjiuxK/G8IZRb58AS8H9NanCUA4VeGsd4UAEvFdXczkKO5k4APmkU5L 4UlgU/4y95b2OpfMQCJgw1IgTp9OVHGbcDbAq6OX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAqr jYtFiTldzZRC00q4e7A7QeGPwRoLEemQGyIImDorgm86rI+yX7cGd19dSFd
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/CuOrvi02AGq0jB_fuGL5vSk_7_U>
Cc: mpls@ietf.org
Subject: [mpls] Review of draft-rosen-mpls-rfc3107bis
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 02 Aug 2016 16:30:46 -0000

I have done a review of draft-rosen-mpls-rfc3107bis on behalf of the MPLS Review
Team.  

The draft is a candidate for WG adoption and is targeted at obsoleting RFC 3107.

The work proposes a number of clarifications and fixes to RFC 3107 intended to
resolve interoperability issues, and removes an optional feature that does not
appear to have been implemented.

I think that the WG should pounce on this document, adopt it at once, and move
it rapidly to RFC status. It is a classic case of something that can and should
be moved ahead without delay.

There are a few minor things that should be resolved before publication as an
RFC. I do not believe these changes need to be made before adoption.

Thanks,
Adrian

- - - - -

Issues


I think the current text of Section 1 ("Introduction") is really good material
and should be retained. But I don't think it is the right text for an
Introduction
recalling that the document is supposed to stand in its own right without having
to read 3107.

I suggest....

1. Introduction

   This document specifies encodings and procedures for using BGP to
   indicate that a particular router has bound either a single MPLS
   label or a sequence of MPLS labels (organized as a contiguous part of
   an MPLS label stack) ([RFC3031], [RFC3032]) to a particular address
   prefix.  This is done by sending a BGP UPDATE message with its
   Network Layer Reachability Information field set to contain both the 
   prefix and the MPLS labels, and with its Next Hop field identifying 
   the node at which said prefix is bound to said labels.  Each such
   UPDATE also advertises a path to the specified prefix, via the 
   specified next hop.

   This document replaces and obsoletes [RFC3107].  It defines a new BGP
   Capability to be used when binding a sequence of labels to a prefix;
   by using this Capability, the interoperability problems alluded to
   above can be avoided.  This document also removes the unimplemented
   "Advertising Multiple Routes to a Destination" feature, while
   specifying how to use [ADD-PATHS] to provide the same functionality.
   This document also addresses the issue of the how UPDATEs that bind
   labels to a given prefix interact with UPDATEs that advertise paths
   to that prefix but do not bind labels to it.  However, for backwards
   compatibility, it declares most of these interactions to be matters
   of local policy.

   It is believed that implementations that conform to this document 
   will interoperate correctly with existing deployed implementations
   of [RFC3107].

1.1. Changes from RFC 3107

   This document obsoletes RFC 3107 [RFC3107] that previously specified
   this function.

   Although there are many implementations and deployments of RFC 3107,
   there are a number of issues with that document that have impeded
   interoperability in the past, and may potentially impede
   interoperability in the future.

   This document updates the text of RFC 3107 to address the following
   issues:

    .... and then include the bullet list from the existing text

1.2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

---

There are then too many (i.e., GT.0) references to 3107 in the rest of
the document. Again, the intention is that the document replaces 3107
and stands alone, so backward references to the obsoleted specification
should not exist except in the preamble (above).

I suggest moving such references to the bullet list in 1.1 together
with a description of the problem addressed, and then leaving the 
remaining text as a stand-alone description of the function/process.

I see:
2.1
2.2 twice
2.4 twice

---

Nits

The use of the first person plural in Section 8 sounds a little regal.

idnits shows that a few references have moved on.