The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Folks,

	Here's most of my last call comments.  More may
be sent out later this evening...

IN GENERAL
==========

	Many aspects of this draft - especially those
relating to E-LSPs and L-LSPs and the Pipe Model
seem intuitive and very useful.

	There are several aspects of the uniform model
which appear complex beyond any justification I have
seen for specifying this model.

	There are concepts that have been introduced
almost completely without explanation.  An amazing
example is the concept of the multi-pop PHP that
comes up in section 2.6.6.

	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
purpose stated by Shahram Davari (23 March, 2000), then
it would be useful to state that an example of when it
might be useful is when multiple tunnel hierarchy levels
are within the same administrative domain.

	There are far too many murky statements for the
specification to be useful in producing interoperable
implementations.  For example, from mid-page on page
18:

   "(1) Tunneling Model 1 (either Uniform or Pipe)

   "(2) Tunneling Model 2 (same as Tunneling Model 1 or different Model)"

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.

	The statement that other models (besides Pipe 
and Uniform) may be supported makes me wonder why an
attempt is made to support the Uniform model (it may
be that the draft punts too late on this issue, rather
than to early on issues that derive from the Uniform
model).

	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.

	I agree with the earlier posted comment that the
draft is excessively wordy.  It includes quotations of
large amounts of text from other drafts which are not 
necessary, it has a lot of redundancy and it looks as
if it has been cobbled together incompletely from the
work of several people.  The content is too important 
to be so hard to read.

SPECIFIC COMMENTS
=================

	The first paragraph in the introduction implies
that the same label is used at each hop.  Last sentence 
should read something like "At each LSR along the LSP, 
the label is used to label-swap and forward the packet 
to the next hop."

	Why the 4+ line quote from [DIFF_HEADER] at the 
bottom of page 2, instead of simple stating the need to 
provide flexibility for service providers?

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

	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.

	At the bottom of page 6, the two statements:

  "(*) when the LSR performs label imposition, the incoming packet is
   received unlabelled.

  "(**) when the LSR performs label disposition, the outgoing packet is
   transmitted unlabelled."

are only true if no label stacking occurs.  It may be that 
you are just talking about the (rather difficult to follow)
figure, but it would be better (and more general) if you
use the common terms "ingress" and "egress" rather than the
terms "label imposition" and "label disposition" and simply
replace these lines with:

   "(*) ingress

   "(**) egress"

	Section 2.3 says that determination of outgoing PHB is 
optional yet goes on to say that the default is that outgoing
PHB is identical to incoming PHB.  This would be clearer if
it simply states that the determination is always done and 
the default 'determination' is that the outgoing is the same
as the incoming (this corresponds to the default "local
policy").

	Why the 8 line quote from [MPLS_ARCH] (toward bottom
of page 8)?  Simply change the next paragraph to read:

   "This specification allows that an incoming label ..."

	Same question/observation for the quote at the bottom
of page 9 and top of page 10.

	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.

	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.

	In section 2.6.6 - there are bullets that talk about 
multi-pop PHP.  Currently, there is no standard way to signal 
this - nor is it reasonable to establish one.  The supposed
intent for PHP was to avoid pop-and-look-again behavior in an
egress LSR.  PHP does not currently require the penultimate
LSR to look at the label it has exposed by popping the label
stack  - so it has no means to determine that it needs to do
a second (or subsequent) pop, even if it is otherwise capable
of performing a pop-and-look-again.  These bullets should be
removed. (I'm pretty sure that there is no other MPLS draft 
that refers to the ability to pop multiple labels as a single 
atomic operation - even at the egress LSR - even though an LSR
implementation can obviously be made to do 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

(Punting on this - as seems to be the current approach
 is just messy :-)

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.



NITS
====

top of page 3 'eg.' should be 'e.g.' (two cases in the 
first paragraph on this page).  Same for top of page 4
(3 occurrences).

first paragraph in section 2.1, last sentence - can't
quite figure out what you're saying.  Suggested rewording
is:

"... the way to determine the PHB to be applied to a
 received packet and to encode the PHB into a transmitted 
 packet is different than for a non-MPLS Diff-Serv Router."
                     --------