The MPLS WG Archive

[Grenville Armitage <gja@dnrc.bell-labs.com>]

George, Vijay,

> This message marks the beginning of a last call on
> draft-ietf-mpls-diff-ext-05.txt, MPLS Support of Differentiated
> Services.
> 
> The last call ends June 26, 2000 at mid-night GMT.
> 
> ...George

So, here are some formal Last Call comments on the I-D
draft-ietf-mpls-diff-ext-05.txt, "MPLS Support of
Differentiated Services".

In principle I think this document provides suitable
technical solutions for indicating DS-style PHBs using
various types of MPLS encapsulation.

However, the document's editorial process is clearly only
in its early stages, and the I-D ought not be progressed
as currently written.

Specifically I found that the structure and wording of most
sections to be extremely verbose and repetitive, such that it
was necessary to re-read many paragraphs a few times just to
be sure of what was being said. There is also a rather high
ratio of speculative to normative text scattered throughout
the document. It will be far clearer to read and implement when
another editorial pass moves speculative text (discussions of what
could have been, might be, or might not be...) to their
own sections clearly separated from the normative text (such
as what E-LSP and L-LSPs actually are, recommended default EXP<->PHB
mappings, etc).

Section 11's discussion of ECN is also unrelated to the ostensible
goals of a document chartered to describe "MPLS Support of
Differentiated Services". ECN isn't mentioned in the abstract or
intro section (not surprisingly, since ECN isn't part of Diffserv).
Section 11 itself appears to be unsure of whether it is speculative
or normative.

******** Specific recommendations:

#1 Remove section 11.

   This can quite reasonably become another document discussing
   experimental ways in which the EXP bits can be used to support
   what even the current text admits is an experimental RFC.
   It has no place in a normative spec relating MPLS and Diffserv,
   and ought to be removed.

#2 Cite work on "MPLS Fast Restoration"

   This phrase is used a number of times in section 1's intro,
   yet there is no specific work cited to explain just what
   this feature is. Since the intro claims that this I-D provides
   support for protecting classes of service "..via MPLS Fast
   Restoration" the technique needs to be cited. If some example
   cannot be cited, alternative introductory wording ought to be
   used. (Oddly this phrase morphs into "Fast Reroute" in the
   appendices - please use one or the other consistently
   throughout the document. Citation is important because even
   in the appendices it isn't clear why this particular mode of
   operation benefits from the extenions being discussed in this
   document.)

#3 Define E-LSPs once only.

   Right now sections 1.2 is the first definition of E-LSP.
   It is relatively concise, and doesn't need to be repeated.
   Specifically, in section 3.1 the two lists of bullet items
   (beginning with "Recognizing that" and "We define that")
   are verbosely redundant and add little. A reverse ref.
   to section 1.2, with some additional clarification, is
   all we need.

#4 Define L-LSPs once only.

   Section 1.3 defines L-LSPs concisely, and section 4.1
   is verbosely redundant with section 1.3. Section 4.1 ought
   to ref. back to 1.3 with only minimal additional clarificatory
   text.

#5 Vastly simplify sections 2.6.3 and 2.6.4 (tunnel models)

   The last paragraph of 2.6.4 admits that basically the only
   difference between the Uniform and Pipe models is in the
   push/pop behaviors. At the very least 2.6.4 can be vastly
   simplified by simply specifying the 'Pipe Model' in terms
   of how it differs from the 'Uniform Model' in 2.6.3 (right
   now 2.6.4 contains a load of redundant descriptive text).

#6 Section 2.6.3, 2nd Figure

   There's a "(P)" floating to the right of "(outer header)"
   that perhaps ought not be there?  (Same for 2nd figure in
   section 2.6.4)

#7 Clarify 2.6.5

   Section 2.6.5's last sentence attempts to be normative about
   something it simultaneously declares out of scope for this
   document. Please clarify, reduce, or remove this section (the
   essence can be stated somewhere earlier in section 2 anyway).

#8 Rationalize sections 3 and 4

   Most of the processing steps are equivalent whether we are
   discussing an E-LSP or L-LSP, so there's very little
   reason to have two sections repeating much of each other.
   (E.g. for filling out things like Encaps<->PHB mappings the
    rules for E-LSPs are essentially a subset of those for L-LSPs,
    sections 3.5 and 4.5 are practically identical,
    section 3.3 is a subset of 4.3, etc...)
   A lot of the wording in both sections ought to be tightened
   up significantly to focus primarily on the normative
   statements. (Indeed, these two sections could probably be
   beneficially collapsed into one section.)

#9 Preconfigured E-LSP EXP<->PHB mapping?

   Section 3.2.1 talks about a preconfigured EXP<->PHB mapping
   but does not suggest a default. I think the document ought to
   specify an actual default for EXP 000 to map to Best Effort PHB
   (or set of defaults where *all* EXP values map to BE).

#10 Why is section 7 here?

  Section 7 repeats material that is redundant for a reader who
  gets this far into the document. Clearly the mechanisms for
  handling MPLS over PPP are documented elsewhere, and this
  document has already stated how various Encaps<->PHB mappings
  are built for E- and L-LSPs. Section 7 ought to be removed,
  perhaps to an informational/applicability document.

#11 Why are sections 8 and 9 here?

  Sections 8&9 suffer the same question of focus as section 7.
  How an ATM or FR interface operates is pretty much covered by
  existing MPLS documents - excluding perhaps the recommendation
  to use EPD for ATM, I dont see sections 8&9 adding anything
  normative to what has already been stated earlier in the document.
  They ought to follow section 7 into another document (or oblivion).

#12 Why is section 10 here?

   Again, as with section 7 there's an issue of focus here.
   No new normative text exists here, and it is at best a subset
   of section 7 anyway.

#13 Remove references to PIM as a label distribution mechanism

   In sections 3.1 and 4.1 the last paragraph speaks about MPLS using
   a variety of label distribution mechanisms, including PIM.
   The reference to PIM should be removed (unless there's a citeable
   *working group* document I'm unaware of for using PIM in this
   manner).
  
#14 Explicit cite for MPLS/BGP

   In the same paras as mentioned above, citation would be useful
   for the references to BGP being used to distribute labels
   (presumably it is [MPLS_VPN] ?)  However, it would also be
   worthwhile rephrasing the citation to not imply this is an
   MPLS WG sanctioned solution (unlike LDP, CR-LDP, and RSVP-TE
   which are WG sanctioned).

I look forward to the revised document providing much appreciated
clarity and guidance to the industry.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley