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

["Adrian Farrel" <[e-mail]>]

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.