Subject: Last call comments

From: Eric Gray <[email-masked]>
Date: Mon, 26 Jun 2000 17:29:54 -0700

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 28 Jun 2000 10:42:10 +0200

Eric,

>be sent out later this evening...

Two motivations are already mentiond in the draft for why the Uniform model is
seenm 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.

>comes up in section 2.6.6.

You are correct. The last paragraph of section 2.6.6 should be removed as it
does not discuss a useful situation. thanbks for catching that.

>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 feel that PHP has been justified enough by the MPLS architecture document.

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

As Shahram explained, the point here is that the two levels of tunnels don't
have to use the same tunneling modes. I believe this must be said. I let
Shahram work with you on better wording.

>    or in different Tunneling Models."

this is the same point.

>than to early on issues that derive from the Uniform

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

>work of several people.  The content is too important 

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?
should we also state the same regarding how the router decides to establish
E-LSPs and L-LSPs and use Configured-mapping instead of signaled mapping etc ?

>makes no sense, given that - in the bullets that precede

the statement is actaully correct. What needs to be changed is the fact that it
is the Local Policy/Traffic Conditioning which is optional (rather than the
Outgoing PHB determination). We'll do that.

>replace these lines with:

agreed.

>as the incoming (this corresponds to the default "local

see above,

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

I think we are in the realm of editorial style here. We have had multiple
requests for clarifying the relationship of this spec to the ARCH. Quoting the
paragraph gives the exact context to which the following statement relates.  I
see it as valuable and think it makes reading easier. 
It doesn't terribly matter to me, though . 

>of page 9 and top of page 10.

same as above.

>model (which makes it necessary to recover this information) is

that is not what it is concluding.

here's the train of thought:
        - (a) LSPs look from above like tunnels---> (b) thus the DS models
applying to tunnels apply to LSPs
        - (c) LSPs have minor transport differences -->(d) thus we need to
accomodate those
except w've stated it as 
(a)+(b)-->(c)+(d)

No?

>and about two pages of text.

Not agreed . See above.

>implementation can obviously be made to do this.)

Agreed. The text on multi-pop PHP in 2.6.6 will be removed.

>(Punting on this - as seems to be the current approach

fine

>               Set of PHBs applicable to an Ordered 

I would prefer to leave them out.
As you may recollect the concepts of OA and PSC have come out of this work on
DS over MPLS. We initially created teh definition and had them in this
document. Now that ownership of these acronyms/definitions has been fully
transfered to the Diff-Serv group and that there are in teh process of being
finalised , I think we should just refer to the appropriate document as
currently done.

> packet is different than for a non-MPLS Diff-Serv Router."

you're proposing to replace "different to" by "differnet than" (or did I miss
other proposed changes?).
then fine.

thanks

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:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________