The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Shahram,

	Please understand that I am not attacking the
current version of the draft.  George gave us a short
amount of time in which to 'give it our best shot'.

	Bang.  :-)

	Please see below.  For the sake of brevity, I
have heavily edited included text without inserting
appropriate <snip> indications...

> >
> >   "(1) Tunneling Model 1 (either Uniform or Pipe)
> >
> >   "(2) Tunneling Model 2 (same as Tunneling Model 1 or 
> >different Model)"
> 
> This is a useful statement. We just need to change the 
> wording. For example
> to:
> 
>   "(1) Tunneling level 1 (either Uniform or Pipe)
> 
>   "(2) Tunneling level 2 (either Uniform or Pipe)"
> 
> Do you see anything wrong with this new wording?
> 

Part of the problem, is that I do not believe that
two models are needed.  I mention that in separate
mail, so I will suspend disbelief for most of this 
reply.  This is NOT the same as placid acceptance 
of the 2 models.

This wording is not much clearer.  I might suggest 

   "(1) Tunneling level 1
    (2) Tunneling level 2

   "The relationship between the two levels may be
    based on either the Pipe or the Uniform model."

Note that the model relates to how the two levels
INTERACT and therefore is not a characteristic of
the levels themselves.

The problem that still remains with the suggested 
text is that it still does not convey the meaning
you want.  Thus I would further suggest

   "(1) Tunneling level 1
    (2) Tunneling level 2
    (3) Tunneling level 3

   "The relationship between levels 1 and 2, and
    between 2 and 3 may be based on either the
    Pipe or the Uniform model. The relationships 
    need not be the same in all cases."

> 
> >Or at the bottom of page 16, top of page 17:
> >
> >   "LSRs at different levels of LSPs are expected to operate 
> >in the same 
> >    or in different Tunneling Models."
> >
> >I believe these may be examples of an earlier comment 
> >on mixing of example deployments and normative text.
> >
> 
> This is actually a normative text. Let me re-write it and see 
> if you agree:
> 
> "It is not necessary for the LSRs at different 
>  levels of LSPs to operate in the same tunneling 
>  mode".

An interestingly complicated statement.  If an
LSR is used to carry (perhaps tunneled) labeled
packets, even when it does not see the (tunneled)
labels, is the LSR _at_ the level of these labeled 
packets?

Maybe

   "In multilevel LSP tunneling, there is no
    requirement for consistent tunneling modes
    at all levels."

Note that this is not phrased as a positive
statement (DO ... as opposed to DON'T DO ...)
and I'm not sure how it could be.

> >	There are many repeat definitions of Acronyms
> >(places where the expanded version is followed by the
> >Acronym in parentheses).  This makes the draft look 
> >as if it was glued together from many pieces.  Either
> >the acronyms should be collected, or only the first 
> >instance should show both.  Currently, there are many
> >cases where the acronym is first used before being 
> >defined.
> 
> There are many new concepts in this draft, that are not 
> published in any document before. Besides this is a large 
> document, and finding the first instance of an acronym 
> is not easy. I don't see any harm in writing the expanded 
> version, if it makes reading the text easier. 
> However, this is an editorial issue and if others object, 
> we can easily remove the expanded versions.

Or you could add a section that defines the acronyms.
I think somebody may have thoughtfully provided you
with the text for this section.

BTW - the fact that there are many new concepts in
this draft (notably the two models) is part of the
problem I'm having with the fact that it is going
through 'last call' right now.

  ... <text justifying redundancy moved to new thread> ...

> 
> >	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)?
> 
> Signaled BW can potentially be used for all of the above. 
> The way to identify which one, and how, is out of the 
> scope of this document (New extensions to signaling may 
> be required). All we have tried to do is to not preclude 
> BW signaling in MPLS+Diffserv operations the way that CoS 
> object did), that is all. If you like we can write that 
> the details are outside the scope of this document. 

My opinion: it is not particularly useful to declare work
that MUST be done before the current work is useable as
"out of scope" unless it is not important HOW it is done.
Otherwise, a likely result of the current work is that it
will succeed only in making more new work than it manages 
to complete.  This - I believe - is in the category of
diminishing returns and should be discouraged.  In this 
case, it is important HOW it is done.  Otherwise, signaling
bandwidth will not be both useful and interoperable.  Plus,
one of the points I am making is that at least one possible
case was omitted.

> 
> >
> >	In section 2.1, this statement:
> >
> >  "Obviously, to enforce the Diff-Serv service 
> >   differentiation the LSR MUST also apply the 
> >   forwarding treatment corresponding to the
> >   Outgoing PHB."
> >
> >makes no sense, given that - in the bullets that precede
> >it - determination of the outgoing PHB is optional.  The
> >bullet - based on following text - should say something to
> >the effect that determination of a change in outgoing PHB
> >is optional.
> >
> 
> Off course determining the outgoing PHB is mandatory. The 
> optional part is determining it through local policy and 
> traffic conditioning. 
> How about this new wording for the 2nd bullet:
> 
>  - Outgoing PHB Determination, which may be a copy of the 
>    incoming PHB or may be via optional Local Policy and 
>    Traffic Conditioning (B).

Okay.

> >	The statement "Based on these considerations ..." in
> >the last paragraph of section 2.6.2 seems to be a non-sequitur
> >- I cannot see the connection between the "considerations"
> >and the conclusion.  For one thing, it seems almost to conclude
> >that - because there is PHP in MPLS, and this makes it hard to
> >determine what the EXP field was at the egress, then the uniform
> >model (which makes it necessary to recover this information) is
> >justified.
> >
> 
> May be we should say "based on these observations...".
> But I can't understand why you can't see any connection 
> between the first 3 bullets and the conclusion? In the 
> first 3 bullets We have shown that from the Diffserv 
> perspective an MPLS tunnel basically is a tunnel, very 
> similar to IP tunnel. So for Diffserv purpose we can use 
> the same tunneling modes as the IP tunnel.

Help me out here, by pretending I'm really very stupid.

Are the Pipe and Uniform models characteristic of IP
tunnel support for DiffServ that is documented in one
or more of the references listed in this draft?  If
so, which reference?

The first 3 bullets do indeed show that MPLS support
of DiffServ is in some ways like IP tunneling support
of DiffServ.  The second set of 2 bullets shows that
MPLS support of DiffServ may be unlike IP tunneling 
support of DiffServ in one way (see BTW below).  From
these considerations, I would conclude that DiffServ
over MPLS may be like and unlike DiffServ support over
IP Tunnels.  Not a very useful conclusion.

Is one of the two models intended to represent DiffServ
support over MPLS that is identical to DiffServ support
over IP Tunnels?  If so, this is far from clear.

BTW - the fact that there is no standard way to do PHP
for IP tunneling is not the same as saying it cannot be
done.  You could look at it as proxy termination of an
IP tunnel.  Also, as it is possible for IP-in-IP tunnels
to be nested, it is also possible to terminate more than
one level of IP-in-IP tunneling at the same point in the 
network.  To say that the fact that LSPs are used in MPLS 
(nested or otherwise) makes MPLS different from IP tunnels
is not a particularly interesting tautology.

So, how do you arrive at the conclusion that two models
are required based on the (boiled down) observation that
MPLS support of DiffServ is like IP Tunnels support of
DiffServ?  Please spell it out for me.

> 
> >	I believe that the uniform model should receive the same
> >treatment as "other models" - i.e. - it should be treated as out
> >of scope.  This removes a lot of seeming unjustified complexity 
> >and about two pages of text.
> 
> Why? What would you do if you hadn't had MPLS? the Diffserv 
> operation in Uniform model is exactly identical to Diffserv 
> over non-MPLS network. Do you also think that we should 
> remove the support of Diffserv transiting non-MPLS networks? 

I haven't seen a draft or RFC on supporting DiffServ over IP
Tunnels.

I do not see one listed as a reference in the MPLS-DiffServ
draft.  

Therefore, I have to go with what I have seen for IP in IP 
tunneling.  The RFC (RFC 2003) for this states that the IP
header in the tunneled IP packet is left alone except for
changing the TTL value.  This implies to me that - for IP 
in IP tunneling at least - the combination of DiffServ and 
IP in IP tunneling results in what we are currently calling 
the Pipe model.  This makes a surprising amount of sense to
me.  From this, I conclude that the "Uniform" model is an 
aberration and I ask for better justification for it than I 
have seen so far.  At the most, it may be necessary to state
that the EXP bit values may be derived from corresponding 
values in a popped label.  See other mail for wording on this.
 
> >
> >	The draft needs a list of acronyms and/or a glossary.  
> >The acronyms used (and, in some cases, introduced) in this 
> >draft include:
> >
> >BA		Behavior Aggregates
> >DSCP		Differentiated Services Code Point
> >EXP		EXPerimental (bits)
> >E-LSP		EXP-Inferred-PSC LSP
> >FEC		Forwarding Equivalency Class
> >FTN		FEC-To-NHLFE Map
> >ILM		Incoming Label Map
> >LSP		Label Switched Path
> >LSR		Label Switch Router
> >L-LSP		Label-Only-Inferred-PSC LSP
> >MPLS		Multi-Protocol Label Switching
> >NHLFE		Next Hop Label Forwarding Entry
> >OA		Ordered Aggregate
> >PHB		Per Hop Behavior
> >PSC		PHB Scheduling Class
> >

Oh, wait.  What's this?  it looks like a partial list 
of acronyms.  :-)

> 
> Thanks,
> 
> -Shahram
>