The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Last Call feedback on MPLS-Diff-Serv
Francois,
I doubt that characterizing Grenville's comments
as mainly editorial is entirely accurate. :-)
See replies below.
> -----Original Message-----
> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: Monday, June 26, 2000 1:06 PM
> To: gja@dnrc.bell-labs.com
> Cc: mpls@UU.NET
> Subject: Re: Last Call feedback on MPLS-Diff-Serv
>
>
> 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.
Okay. Here's my opinion (assume the usual disclaimer).
I agree with you that - if there was a standard (or even a
reasonably mature draft of a standard) approach for using
one or more of the EXP bits for ECN - then MPLS-DiffServ
would need to either state that the two usages are mutually
exclusive, or specify how they work together.
As I recall, however, the draft on this subject was not too
well received and the authors have not had sufficient time
and/or interest to re-fresh it on the ftp server. Note that
I am not opposed to the idea, but I have issues with the way
in which it seems to keep cropping up in unexpected ways.
I'm not convinced that there's anything sneaky going on with
this. In fact, I'm fairly convinced that there is not. But
the track record for this work does not look good. Luckily,
I'm a naive sort of person who believes in happy acidents and
overwhelming coincidence. :-)
First, the draft was misnamed - making it appear as if it
had already been accepted as a working group draft. Most
likely this was a simple slip up. This was brought up as
an issue after the Oslo meeting.
Then it was added to the MPLS working group Internet drafts
web page as a working group draft - in spite of the fact it
was very definitely NOT accepted as such after the Oslo
meeting. This was, I believe - a result of the combination
of automated web-page production tools and the first unhappy
misnaming accident. This was pointed out at the Washington
meeting.
Then it took several months to correct the web page list to
reflect the fact that this draft was not accepted by the WG.
This delay was certainly impacted by the well-known backlog
on the ID queue as well as work loads elsewhere. The draft
was removed from the MPLS working group drafts site at about
the same time as it expired.
Now it seems as if ECN has been tacked onto the DiffServ draft
like a pork-barrel rider on a congressional appropriations bill.
It's a fortunate thing that my basic naivete is pretty robust.
Since there is no available work on MPLS-ECN, including it
in this draft seems an awful lot like an attempt to boot
strap such work. This might not be a bad thing, but it
would definitely be an out-of-scope activity for a standard's
track document on DiffServ support in MPLS.
Now, you've heard another opinion.
... <snip> ...
>
> >
> >#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.
Alternatively, the Uniform model could be treated as yet
another example of "other models" - i.e. - out of scope.
>
> 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...").
>
... <snip> ...
>
> >
> >#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 looked through the mail archive and was not able
to determine the reason why it was felt to be very
important to include a separate model. It seems to
me that the entire concept can be captured by very
simply stating something like this:
"When a label is popped off of the label stack,
the value in the EXP bits field may either be
copied (or otherwise derived) from the EXP bits
field in the label being removed, or left as is.
Copying (or otherwise deriving) the value from
the label popped to the newly exposed label may
result in changing the value of those bits that
existed previously. This could make sense, for
example, if the LSPs corresponding to the two
labels are both within the same DiffServ domain.
"Deriving the EXP bits value in the newly exposed
label from the EXP bits in the popped label has
implications on PHP behavior. Specifics of these
implications and mechanisms for deriving the EXP
bit values in this case are out of scope for this
document."
Note that you cannot mandate that an LSR performing
PHP MUST be able to perform such a mapping if you do
not specify how such a mapping MAY be done.
With the above two paragraphs, you can delete
all references to two models (Pipe and Uniform) and
all text dealing with 'differences' between them.
Let's try not to make this tougher than it is.
>
> 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
> _________________________________________________________________
>
|
|