The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Hi Eric,

I will leave most of the editorial changes to Francois:

>-----Original Message-----
>From: Eric Gray [mailto:EGray@zaffire.com]
>Sent: Monday, June 26, 2000 8:30 PM
>To: MPLS Mailing List (E-mail)
>Subject: Last call comments
>
>
>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)"

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?


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


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

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.

Could you please clearly identify the acronyms that are use before being
introduced. That way we could correct them.

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

Eric, we are dealing with many combinations and options and modes in this
draft which require stating the precise operation in each case. We have
signaled E-LSP, configured E-LSP, L-LSP, Pipe model, uniform model, with
PHP, without PHP, ATM, FR, PPP, error handling, ...

If we want to remove all the redundancies, then we are left with a mesh of
interconnected text. A reader which for example is interested in L-LSP with
PHP in pipe model in PPP will need to go so many times back and forth in the
document that will probably be confused. This is a potential for
interoperability problem. 

So although it may add to the volume of the draft, but I think it makes
reading the text much easier.

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

Fine.


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

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. 

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


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

Sam as above. We will clarify.

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

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.

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

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

Thanks,

-Shahram