The MPLS WG Archive

[Francois Le Faucheur <flefauch@cisco.com>]

Eric,

At 17:29 26/06/2000 -0700, Eric Gray wrote:
>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.
>

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.



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

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.

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

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

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

this is the same point.

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

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

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

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 ?

>       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

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.

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

agreed.

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

see above,

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

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 . 

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

same as above.

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

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?

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

Not agreed . See above.

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

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

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

fine

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

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

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:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________