The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Francois,

	Thanks for the well considered replies.

	See several embedded replies below.  Please 
pardon the numerous "clippings".


> >
> >       There are several aspects of the uniform model
> >which appear complex beyond any justification I have
> >seen for specifying this model.
> >
> 
> Two motivations are already mentioned in the draft for why the 
> Uniform model is seen as very useful. This summarises 
> discussions we have had on that topic and corresponding 
> conclusions:
> 
> "Use of the Uniform Model allows LSPs to span Diff-Serv 
>  domain boundaries without any other measure in place 
>  than an inter-domain Traffic Conditioning Agreement at 
>  the physical boundary between the Diff-Serv domains and 
>  operating exclusively on the "outer" header, since the 
>  meaningful Diff-Serv information is always visible and 
>  modifiable in the outmost label entry.
> 
>  The Uniform Model for Diff-Serv over MPLS is such that, 
>  from the Diff-Serv perspective, operations are exactly 
>  identical to the operations if MPLS was not used."
> 
> The Uniform model is useful and should stay in this draft.

If the Uniform model is to stay in the draft, then it is
not sufficient to say that the means for mapping the PHB
represented by EXP bits in the label being popped to the
PHB in the newly exposed label is "out of scope".  This
means that there may be significant work left to do for
this draft.  Or not.

The reason why it is not sufficient to punt on this is
because the putative intent is to preserve operations
"exactly identical to the operations if MPLS was not used."
Therefore, the means for ensuring that the PHB that results
from the combination of PHB demotion within an LSP and the
mapping this demoted PHB to a PHB at the LSP egress (or 
penultimate hop) is the same as the PHB that would have 
resulted if the demotion occurred outside of the LSP.

This complication further breaks down into the issue of
whether or not demotion can occur within an LSP and the
issue of how a demotion represented by the flipping of
a single bit is to be mapped to a specific demotion in
a 3 bit EXP field (in an MPLS label) or a 6 bit DS field
(in an IP header).  If the PHB cannot be changed within
an LSP, than the use of the Uniform model is unjustified 
(the field copied outward and then inward cannot have 
changed - therefore the effort to copy it is wasted).
So, for the uniform model to make sense, it must be
possible that the PHB would change (demotion, promotion
or other modification) within an LSP.  I'll allow that
there may be some strange application for nested policing
or traffic conditioning behavior that is expected to have
a concatenated effect on traffic even as it leaves lower
level LSP tunnels, so this may be the case.

>From my reading of sections 3.4.2 and 3.4.3, it appears
to me that demotion may be somewhat problematic if using
either ATM or FR since setting the DE/CLP bit seems to
uniformly transform an EF PHB to an AF PHB.  Unless I've
misunderstood something pretty fundamental, that would
make the new PHB no longer a part of the same OA within
an E-LSP.  Even if this is not an issue, it WILL make 
mapping the result to the same PHB that would have been
the result if MPLS were not used somewhat non-trivial.

(By the way, has anyone considered the impact on ATM
 and FR hardware behavior of using the CLP/DE values
 given in this version of the specification?  Or is it
 the assumption that MPLS over ATM/FR will interpret
 these bits differently in hardware than they have been
 interpreted previously?) 

On the other hand, if the EXP field is used for PHB 
determination within an LSP, I do not see why we need
to say anything more than that the EXP field in the 
label being popped is copied to the label thus exposed
when using the uniform model.  The fact that it might 
be mapped to a new PHB just before, or just after, this 
copy operation (e.g. - based on a local DiffServ domain 
policy) is completely orthogonal to the copy operation 
itself.

So, if my understanding is correct, the only useful
"mapping" of EXP field values at egress/PHP is a copy
operation.  This immensely simplifies what we have to
implement to support the uniform model.  In addition,
it also makes almost all of the discussion of the two
models and differences in related behavior go away.

> 
> >       The draft punts on several relevant issues.  In
> >particular, there seems to be no effort to justify 
> >some of the complexity in the specification in terms 
> >of real world applications for particularly difficult
> >combinations (such as the combination of Uniform model 
> >and PHP).  If the uniform model is intended for the
> 
> See above. You may have missed the earlier discussions on 
> the alias but this was discussed. and there is corresponding 
> text in the spec already giving an example of where uniform 
> is useful.

I did a search (using Netscape's 'Search Messages' function)
for all MPLS related messages containing the word 'uniform'.
I also read the minutes from Adelaide (I'm not going to be
forever apologizing for not having been able to get there).
The 'discussion' in each case was decidedly one-sided.  I
did not notice anyone, other than the authors of the draft,
clamoring for inclusion of the uniform model.  I did a like
search in the DiffServ mailing list - which I already said
something about in a different message - and found a similar
silence from the throngs.

This is the first draft in which the two models are discussed
and it is also the draft on which we have been asked to give
last call comments.  I stated that the Uniform model is not
sufficiently well documented and should be removed.  You say
it stays.

Sounds perfectly reasonable to me.  You still need to address
the issue that it is not sufficiently well documented.

> 
> I feel that PHP has been justified enough by the MPLS 
> architecture document.

Let's not pretend that I didn't say "the combination of 
Uniform model and PHP".                  ===========
              ===

I am perfectly well aware that PHP is here to stay.  The
combination of the Uniform model and PHP is a complexity
that many may find difficult to swallow.  And, unlike PHP
in general, it is a NEW complexity.

> 
> The reason we "attempt" to support uniform is that the 
> group's agreed on the alias that it was useful.

The group 'agreed' (mostly by its silence) that it would
be useful to specify something about the Uniform model.
You folks have made one attempt to do this and my comment
is that it is either not enough, or too much.  See above.

> >
> >       Section 1.6 - can signaled bandwidth also be used 
> >for policing packets associated with a PSC?  How does an
> >implementation know if it is supposed to use signaled
> >bandwidth to perform any of the functions mentioned in
> >this section (adjusting scheduling weights, admission
> >control and, possibly, policing)?
> >
> 
> same as usual: outside the scope of this spec, could be by 
> local config, policy, SNMP,...
> do you think it would add value to state so?

How would you configure which function to apply for each
specific LSP for which bandwidth might be signaled?  Will
this be a global, per-interface or per-LSP parameter?  If
it is supposed to be per-LSP, why bother with signaling?

Can the signaled bandwidth be used for one purpose at one
LSR along the LSP and another at another LSR?  This affects
the scope of configuration since, if it is expected to be
consistent, then it must be configured either per-LSP or
globally within a DiffServ domain.

Is the list of potential functions intended to be exhaustive?  
If so, then it needs more entries.  If not, and the bandwidth 
signaled is intended to be used consistently throughout an
LSP, then what is the minimal set of possible functions that
every LSP should support in order to achieve a useful level
of interoperability?

> 
> >In addition, the following definitions would be useful
> >(collected in a glossary?):
> >
> >Behavior Aggregate
> >               Packets crossing a link that require
> >               the same Diff-Serv behavior.
> >Diff-Serv      Differentiated Services.
> >Diff-Serv Context
> >               <Insert Definition HERE>
> >FEC            <Insert Definition HERE>
> >Ordered Aggregate
> >               Set of Behavior Aggregates sharing an 
> >               ordering constraint.
> >PHB Scheduling Class
> >               Set of PHBs applicable to an Ordered 
> >               Aggregate.
> >
> >
> 
> I would prefer to leave them out.

Okay by me.  It might be useful if there was a statement
somewhere stating where these definitions can be found.
Of course, if the answer is not simple, it might be easier
to just include the definitions.  There are precedents
among the other MPLS drafts.

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