Subject: Last Call on MPLS-Diff-Serv

From: George Swallow <[email-masked]>
Date: Mon, 12 Jun 2000 13:53:05 -0400

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

ps.  I was travelling when the last call for draft-ietf-mpls-lsr-mib-04.txt
     ended (on May 12) so if anyone was waiting for a message, this
     post script will have to do.

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 26 Jun 2000 01:26:22 -0700

George, Vijay,

> The last call ends June 26, 2000 at mid-night GMT.

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

---

From: [email-masked]
Date: Mon, 26 Jun 2000 08:47:03 -0400

Vijay, George, 

On 26 Jun 2000, at 1:26, Grenville Armitage wrote:

> 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).
> 
> 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.
[snip]

I would like to agree with Grenville, and think that rework of this 
draft along the lines he proposes would be quite useful.  

Regards,
Steve 

Stephen Nadas                           Ericsson IP Infrastructure
[email-masked]                    920 Main Campus Drive 
Voice:  +1-919-472-9935 Fax: x/9999     Suite 500
Mobile: +1-919-522-0991                 Raleigh, NC 27606

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 26 Jun 2000 22:05:38 +0200

Grenville,

Thanks for your comments. Since those comments are mainly editorials, we should be able to resolve them reasonably quickly.
Let me jumpt straight to the specific suggestions

At 01:26 26/06/2000 -0700, Grenville Armitage wrote:
[clip]
>   It has no place in a normative spec relating MPLS and Diffserv,

It has been useful and necessary for the WG to understand how ECN could share the EXP space with ECN (should ECN be required in the future), in order to progress with Diff-Serv over MPLS support. It seems appropriate to me to also reflect some of this in the Diff-Serv draft. If we had come up with a Diff-Serv solution that was incompatible with ECN, I think it woudl be useful for that document to say so. It turns out we feel that ECN and Diff-Serv could coexist and that the impact on the Diff-Serv over MPLS solution are reasonable. We might have tried to be too specific in the current text (considering the early stage of ECN over MPLS) but I think some description of why the current Diff-Serv solution does not preclude ECN and how those could share EXP space is useful information.

I'd like to hear other opionions.

>   operation benefits from the extenions being discussed in this

sure, we'll include a reference to a document discussing FAst Restoration.

>   to section 1.2, with some additional clarification, is

Fine.

>   to ref. back to 1.3 with only minimal additional clarificatory

Fine.

>   now 2.6.4 contains a load of redundant descriptive text).

Yes, as pointed out in the draft, the two models "only" differ in their push and pop behaviours. But the push and pop  behaviours (with/without PHP) are the complex aspects discussed in a big part of the text anyway (the swap behavior is quite straight-forward in both models). So , saying they "only" differ by push/pop doesn't mean that you would save that much text by describing operations of Pipe as delta over Uniform.

However, we could simplify 2.6.3 by combining the 2nd paragraph ("With this Uniform Model:...") with the last paragraph ("For support of the Uniform Model over an LSP ...").
Similarly we could simplify 2.6.4 by combining the 3rd paragraph ("With this Pipe Model: ...") with the two paragraphs before last ("For support of the Pipe Model over an LSP..."). 

>   that perhaps ought not be there?  (Same for 2nd figure in

(P) indicates the penultimate LSR in all diagrams. It appears at the right location even in the 2nd figures (ie without PHP). It insists on the fact that in those cases (P) does a swap (and not a pop) so that the "outer header" is there between (P) and (E) to carry some Diff-Serv info .

>   document. Please clarify, reduce, or remove this section 

We can get rid of the word "may" of the last sentence so that it reads:
"Models beyond the Uniform Model and the Pipe Model are outside the scope of this specification but are not precluded by this specification".

>(the

I woudl find it difficult to summarise something that explains that there could be other models, give a potential example of such other models and clarify it is outside the scope of this spec in less than 3 sentences. So I propose to leave it as it is.

>  (Indeed, these two sections could probably be

I am not sure what you are calling the "two sections" (ie 3 and 4 , or 3.5 and 4.5)

Although the descriptions of E-LSPs and L-LSPs have a number of things in common, they have a lot of differences:
	- 3.2 and 4.2 are completely differnet. 3.2 uses preconfigured/signaled mappings applying on EXP only, 4.2 uses MAndatory/Default mappings applying to EXP/CLP/DE.
	- 3.4 and 4.4 are very differnet. 3.4 must have a PHB-->EXP mapping  while 4.4 may or may not have a PHB-->EXP mapping. 3.4 uses configured signaled mapping to populate it. 4.4 uses Mandatory mapping. 4.4 needs to cover the cases  of LC-ATM and LC-FR while 3.4 shoudl not. 4.4.4 is the same as 3.4.4 and already use a refernec to 3.4.4.1.
So section 3 and section 4 could not be collapsed together.

3.3 is indeeed a subset of 4.3, but 3.3 already boils down to a single paragraph so I am not sure we would gain much by replacing that with a cross-reference. Also you might have to clarify that only a subset of the cases are relevant to E-LSPs to avoid confusion. So there is not much to be gained there.

3.5 and 4.5 are the only ones that could usefully be combined. With very minor editing around, 4.5 could be replaced by a reference to 3.5. 

>   statements. 

Could you provide specific suggestions? or at least point us towards the issues you see?

>   (or set of defaults where *all* EXP values map to BE).

The Network Adminsitrator is expected to configure the "preconfigured EXP<->PHB mapping" depending on the BAs that are actually used in his/her network. Since differenet Network Administrators are likely to run differnet subsets of BAs it is difficult to define a Default mapping that would be generally useful. But I guess you are saying , it would be useful to have a default mapping in case the preconfigured mapping hasn't been configured at all by the Network Adminsitrator. Right?
In that case, I suppose I woudl also map all EXP values towards BE. 

Anyone else has thoughts on that?

>  perhaps to an informational/applicability document.

Section 7 is NOT redundant. It specifies , out of all the previously defined options, which ones are MUST and which ones are MAY for PPP interfaces. Unless you specify that you may have one implemnetation supporting one option and another implementation supporting another option which prevents actual interoperability.

We could put that text into a separate applicability document, but I don't see the point of doing this. What we have in there has been proposed and agreed for a while, and I think it is really required to achieve interoperability so that it belongs in this document.

>  They ought to follow section 7 into another document (or oblivion).

Same as above, these sections clarify which of the various options are applicable to these media.
Also it clarifies media specific issues which have come up during the WG progress (eg that the requirement is for ATM LSRs to support PHB scheduling rather than "traditional" ATM scheduling, that only two drop levels are supported , that EPD is a good idea, that the spec only covers the case where the shim layer is used...)

I believe this is useful information and should be kept.

>   No new normative text exists here, and it is at best a subset

Section 10 is NOT redundant. It specifies , out of all the previously defined options, which ones are MUST and which ones are MAY for LAN interfaces. Unless you specify that, you may have one implemnetation supporting one option and another implementation supporting another option which prevents actual interoperability.

We could easily group it with section 7 though.

>   *working group* document I'm unaware of for using PIM in this

Fine.

>   which are WG sanctioned).

fine.

Cherio

Francois

>clarity and guidance to the industry.

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: Bora Akyol <[email-masked]>
Date: Mon, 26 Jun 2000 13:21:32 -0700

Francois

The ECN section as it is written in the document is not detailed enough. The use of only 1 bit for ECN to mean either the LSR is ECN capable and experiencing congestion or the LSR is not ECN capable is at the very least confusing.

This topic has not been widely discussed as part of the DS document. I would suggest that you remove section 11 and submit it as another ID and ask for WG to adopt this document. Then we can discuss the ECN compatibility with MPLS-DS extensions as part of the new document.

As presented in v05, the ECN section leaves too many holes as far as I am concerned.

Bora

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 26 Jun 2000 15:00:59 -0700

Francois,

I'll pull out each major discussion point separately. In this
email my response re ECN.

	[..]
> >#1 Remove section 11.
	[..]
> It has been useful and necessary for the WG to understand how ECN could
> share the EXP space with ECN (should ECN be required in the future),
> in order to progress with Diff-Serv over MPLS support.

Regardless of the ongoing debates in other mailing lists over the
utility of ECN, it isn't necessary for *this* document to specify
anything regarding ECN support. It is sufficient that diff-ext-05
state ECN isn't precluded, there is no need for diff-ext-05 to
speculate on how ECN might be supported. Leave that for another
document.

I suggest it is sufficient to state the following in the intro,
abstract, and/or conclusion:

 "The architecture described in this document does not preclude the
  signalled or configured use of the EXP bits to support protocols
  such as ECN [ECN][MPLS_ECN]. However, techniques for supporting
  ECN in an MPLS environment are outside the scope of this document."

Done.

cheers,
gja

> It seems
> appropriate to me to also reflect some of this in the Diff-Serv draft.
> If we had come up with a Diff-Serv solution that was incompatible with
> ECN, I think it woudl be useful for that document to say so. It turns
> out we feel that ECN and Diff-Serv could coexist and that the impact on
> the Diff-Serv over MPLS solution are reasonable. We might have tried to
> be too specific in the current text (considering the early stage of ECN
> over MPLS) but I think some description of why the current Diff-Serv
> solution does not preclude ECN and how those could share EXP space is
> useful information.
	[...]

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 27 Jun 2000 09:07:38 +0300 (EEST)

>   ECN in an MPLS environment are outside the scope of this document."

i too think that enc should not be part of this document. the above
wording is fine.

-- juha

---

From: Bora Akyol <[email-masked]>
Date: Tue, 27 Jun 2000 10:16:31 -0700

Juha

Tell us something we did not know already. You are a co-author of this
document, so unless section 11 went in there without you looking, you must
have approved of it ;-)

Bora

---

From: Bora Akyol <[email-masked]>
Date: Tue, 27 Jun 2000 10:31:41 -0700

My apologies.

I take my comment back, I read it way too quickly (and missed the "not" in
Juha's statement) and was punchy at the keyboard. I guess need more coffee
this morning.

Again, my apologies to both Juha and the MPLS WG,

Overall, I think the ECN part of this draft detracts from the main focus of
this draft, I think Greenville's statement in an earlier email should suffice.
If the other authors would like to submit another ID that addresses the full
scope of ECN, I would fully support this.

Bora

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 27 Jun 2000 20:50:02 +0300 (EEST)

> document, so unless section 11 went in there without you looking, you must

there are many things in the i-d that i have not "approved".  i'm
only one of many authors and don't think i have veto rights.  

in addition to the ecn stuff, i, for example, didn't think that we need
more than one kind of lsps and i didn't like the new terms mode terms,
but would have prefered the already existing terms network and service
interworking.

-- juha

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 28 Jun 2000 19:16:39 -0700

Francois,

I'm gradually getting time to continue our discussion of
my other points. In this email, my suggestion #9:

> The Network Adminsitrator is expected to configure the
> "preconfigured EXP<->PHB mapping" depending on the BAs that
> are actually used in his/her network. Since differenet Network
> Administrators are likely to run differnet subsets of BAs it is
> difficult to define a Default mapping that would be generally
> useful.

Agreed, generally useful non-BE mappings would be hard to
get WG agreement on.

> But I guess you are saying , it would be useful to have
> a default mapping in case the preconfigured mapping hasn't been
> configured at all by the Network Adminsitrator. Right?

Yes. I contemplated suggesting a set of eight BAs, but
didn't want to open up a can of worms regarding which
eight BAs are important enough to mandate that an LSR
support. So....

> In that case, I suppose I woudl also map all EXP values

Yes, I think it would be beneficial for the text to at least
nominate the default behavior for every EXP value (or at least
EXP=000) to be Best Effort. Although such a default is kind
of intuitive, its worth stating. The text can easily reassure
readers that local configuration is always entitled to override
the default.

cheers,
gja

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 29 Jun 2000 13:56:15 +0200

Grenville,

>readers that local configuration is always entitled to override

makes sense to me. unless someone raises issues with this, we will add that default mapping.
thanks

Francois

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 29 Jun 2000 16:34:44 -0700

Francois,

Continuing discussion of section 2.6.5:

> We can get rid of the word "may" of the last sentence so that it
> reads: "Models beyond the Uniform Model and the Pipe Model are
> outside the scope of this specification but are not precluded by
> this specification".

Assuming 2.6.5 is needed, it would be sufficient for the final
sentence to read "Models beyond the Uniform Model and the Pipe
Model are outside the scope of this specification."

However....

> I woudl find it difficult to summarise something that explains
> that there could be other models, give a potential example of
> such other models and clarify it is outside the scope of this
> spec in less than 3 sentences. So I propose to leave it as it is.

Since I dont think this document even needs to speculate on the
form of alternative models beyond Uniform and Pipe, there's really
no need for multiple sentences. And in fact the intent of 2.6.5 would
be captured perfectly by modifying the last paragraph of
section 2.6.2 (where the modelling scope of 2.6 is described) to
conclude with:

  "[..]These two models are the Uniform Model and the Pipe Model and
   their operations over MPLS is described in the following sections.
   Discussion and definition of alternative tunneling models are
   outside the scope of this specification."

(Defining something as outside the scope of "this specification"
automatically leaves the door open for future specifications to
cover such things)

Voila, section 2.6 now simplified :)  This is my recommendation.

cheers,
gja

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 29 Jun 2000 16:59:46 -0700

Francois,

Use of "(P)" in second figures of 2.6.3 and 2.6.4:

> (P) indicates the penultimate LSR in all diagrams. It appears at the
> right location even in the 2nd figures (ie without PHP). It insists
> on the fact that in those cases (P) does a swap (and not a pop) so
> that the "outer header" is there between (P) and (E) to carry some
> Diff-Serv info .

Okay, I now understand the intent. But now I'm not sure the ASCII art
is clear. In the non-PHP examples the "(P)" _appears_ to sit two hops
prior to the "(E)" LSR, which is confusing. (Alternatively, it isn't
clear from the ASCII art how to distinguish LSRs and links and
therefore derive the message you intend about where the egress
hops and penultimate hops exist. I can't figure out if the "(M)"
represent LSRs or links using 'meaningful diffserv info' - my
initial read took them as LSRs.) Perhaps the ASCII art could
be clarified (or we could just assume readers know that non-PHP
means "label swap all the way"?)

cheers,
gja