The MPLS WG Archive

[Francois Le Faucheur <flefauch@cisco.com>]

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]
>
>******** 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.
>

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.

>#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.)

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

>
>#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.
>

Fine.

>#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.

Fine.

>
>#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).
>

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..."). 

>#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)

(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 .

>
>#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 

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
>   essence can be stated somewhere earlier in section 2 anyway).
>

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.

>#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...)

>  (Indeed, these two sections could probably be
>   beneficially collapsed into one section.)

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. 

>   A lot of the wording in both sections ought to be tightened
>   up significantly to focus primarily on the normative
>   statements. 
>

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


>#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).
>

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?

>#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.

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.

>
>#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).
>

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.

>#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.
>


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.


>#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).
>  

Fine.

>#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).
>

fine.



Cherio

Francois

>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
> 

_________________________________________________________________
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:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________