Subject: RE: Last call comments

From: Eric Gray <[email-masked]>
Date: Tue, 27 Jun 2000 19:35:36 -0700

Shahram,

	A few people pointed out that there is a draft
(newer than the one listed in the MPLS-DiffServ
draft) which I had missed earlier on the web page
for DiffServ working group drafts.

    http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-01.txt

This draft does define Uniform and Pipe models.  I
read the part of this draft that defines these two
models and still am not sure why the Uniform model
is needed, but I assume that there has been a lot
of discussion on this on a mailing list which I've
admittedly paid less attention to (though a quick
screening of the mail archive only turned up one
comment on the topic in the last 9 or 10 months).

	However, now that I know where this comes from,
I am even more convinced that this should be treated
as out of scope for the MPLS DiffServ draft.  My
thinking is based on the considerations that the draft
on DiffServ tunnels is only in its second iteration as 
a working group draft (and may be relatively immature)
and was downgraded (from a standards track draft) to an
Informational RFC track document just a few days ago.  
The current level of maturity for that draft means that 
it is possible that one or the other of the two models 
may still be removed and the fact that it is now meant 
to be informational means that there is less incentive 
for working group members to expend effort to ensure 
that it accurately reflects what the implementers are 
really implementing and the users are really using.

	That draft currently assumes that the DS field is
strictly copied (from inner to outer on tunnel ingress
and from outer to inner on tunnel egress).  Clearly,
the restrictions imposed by mapping the DS byte to the
smaller EXP field (or DE/CLP bit) means that there may
not be a consistent way to "copy" this information from
one label to another.   However, this fact means that 
the process of mapping one value to the next will most
likely result in information loss.  This information
loss will most probably lead to degradation in service 
intended for DiffServ labeled packets - since it seems 
unlikely to be a good policy to always upgrade service 
in this case.  Consequently, the Uniform model is very
unlikely to be useful when it is not possible to copy
EXP bit values from one label to another.

	On top of this, the discussion I expected to see
in the DiffServ mail archive was a discussion of the
consequences of 'punishing' packets that have made it
through a tunnel successfully by carrying forward any
degradation in their service that may have occurred 
while transiting the tunnel.  Typically there is some
cost associated with tunneling packets and this is a
'sunk cost' once the packet has succeeded in making
it through the tunnel.  It then seems a little strange
to drop this packet at a congestion point when it was
not dropped within the tunnel and would not have been
dropped if it still had the PHB it had on entering the
tunnel.  This may be a 'belief system' issue but, when
combined with the likelihood of losing information in
mapping (as opposed to copying) EXP bit values from
one label to another, there seems to be less reason
to explicitly specify this behavior in MPLS DiffServ.

	Minimally, the draft needs to say a lot less on
the subject of the two models in order to avoid being
locked into a position in which it 1) cannot be moved
forward until the DiffServ Tunnels draft is progressed
and 2) is inconsistent in its usage with that work.

--
Eric Gray

---

From: Shahram Davari <[email-masked]>
Date: Wed, 28 Jun 2000 12:00:56 -0700

Eric,

Thanks for your comments. Here are some answers:

>-----Original Message-----
>From: Eric Gray [mailto:[email-masked]]
>Sent: Wednesday, June 28, 2000 1:29 PM
>To: 'Francois Le Faucheur'
>Cc: MPLS Mailing List (E-mail); Eric Gray
>Subject: RE: Last call comments
>
>
>Francois,
>
>	Thanks for the well considered replies.
>
>	See several embedded replies below.  Please 
>pardon the numerous "clippings".
>
>
>> >
>> >       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 mentioned in the draft for why the 
>> Uniform model is seen 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.
>
>If the Uniform model is to stay in the draft, then it is
>not sufficient to say that the means for mapping the PHB
>represented by EXP bits in the label being popped to the
>PHB in the newly exposed label is "out of scope".  This
>means that there may be significant work left to do for
>this draft.  Or not.

Eric, let's not confuse people. We didn't say that in the Uniform model, the
mapping from top label to the lower label is out of the scope. What we  said
is that if PHP is not used, then Uniform model can be implemented easily,
because the egress node HAS the mapping information for both top and lower
label. While in the PHP case, the penultimate node requires mapping
information for the lower label, that it normally does not have. 

What we said is that the way to provide this information in the PHP mode is
out of the scope of this draft. That doesn't mean that people can't use
Uniform model NOW, the non-PHP mode can always be used successfully and
easily. 

>
>The reason why it is not sufficient to punt on this is
>because the putative intent is to preserve operations
>"exactly identical to the operations if MPLS was not used."
>Therefore, the means for ensuring that the PHB that results
>from the combination of PHB demotion within an LSP and the
>mapping this demoted PHB to a PHB at the LSP egress (or 
>penultimate hop) is the same as the PHB that would have 
>resulted if the demotion occurred outside of the LSP.
>

Please see above.

>This complication further breaks down into the issue of
>whether or not demotion can occur within an LSP and the
>issue of how a demotion represented by the flipping of
>a single bit is to be mapped to a specific demotion in
>a 3 bit EXP field (in an MPLS label) or a 6 bit DS field
>(in an IP header).  

Yes, the PHB might be changed (even the diffserv WG has not intentionally
precluded traffic conditioning within a network). What you are talking is
mapping from top label, which is an L-LSP to the lower label which is an
E-LSP, or to the IP header (DSCP). This is easily done in ultimate hop
(non-PHP), because ultimate hop is acting as an LSR for both upper and lower
label, and therefore has all the mapping information for both.

If the PHB cannot be changed within
>an LSP, than the use of the Uniform model is unjustified 
>(the field copied outward and then inward cannot have 
>changed - therefore the effort to copy it is wasted).

Please see above.

>So, for the uniform model to make sense, it must be
>possible that the PHB would change (demotion, promotion
>or other modification) within an LSP.  I'll allow that
>there may be some strange application for nested policing
>or traffic conditioning behavior that is expected to have
>a concatenated effect on traffic even as it leaves lower
>level LSP tunnels, so this may be the case.

Sure.

>
>From my reading of sections 3.4.2 and 3.4.3, it appears
>to me that demotion may be somewhat problematic if using
>either ATM or FR since setting the DE/CLP bit seems to
>uniformly transform an EF PHB to an AF PHB.

I think you have misunderstood these sections. As we have mentioned in the
draft, LC-ATM interfaces can not support E-LSP (they only support L-LSP).
That is why in these sections we have talked about non-LC-ATM interfaces. By
that we mean an E-LSP which is transiting a  Normal ATM network. To do so
you obviously need one VC per PSC. So when we talk about PHB->CLP mapping,
we actually mean Drop Precedence ->CLP mapping, and we have assumed that the
PSC is derived from the VC (or VCID). So it is impossible to transform from
EF to AF by flipping CLP bit.

  Unless I've
>misunderstood something pretty fundamental, that would
>make the new PHB no longer a part of the same OA within
>an E-LSP.  Even if this is not an issue, it WILL make 
>mapping the result to the same PHB that would have been
>the result if MPLS were not used somewhat non-trivial.
>
>(By the way, has anyone considered the impact on ATM
> and FR hardware behavior of using the CLP/DE values
> given in this version of the specification?  Or is it
> the assumption that MPLS over ATM/FR will interpret
> these bits differently in hardware than they have been
> interpreted previously?)

As I said, CLP/DE bits are always interpreted as drop-precedence. Be it in
ATM, MPLS, or this draft.

>
>On the other hand, if the EXP field is used for PHB 
>determination within an LSP, I do not see why we need
>to say anything more than that the EXP field in the 
>label being popped is copied to the label thus exposed
>when using the uniform model.

Because various levels of the tunnel may use different EXP<->PHB mapping.

  The fact that it might 
>be mapped to a new PHB just before, or just after, this 
>copy operation (e.g. - based on a local DiffServ domain 
>policy) is completely orthogonal to the copy operation 
>itself.

Please see above.

>
>So, if my understanding is correct, the only useful
>"mapping" of EXP field values at egress/PHP is a copy
>operation.  This immensely simplifies what we have to
>implement to support the uniform model.  In addition,
>it also makes almost all of the discussion of the two
>models and differences in related behavior go away.
>

This is not generally true. This is only true if different levels of
hierarchy use exactly the same mapping, and the upper and lower label are
the same type of LSP.

>> 
>> >       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 did a search (using Netscape's 'Search Messages' function)
>for all MPLS related messages containing the word 'uniform'.
>I also read the minutes from Adelaide (I'm not going to be
>forever apologizing for not having been able to get there).
>The 'discussion' in each case was decidedly one-sided.  I
>did not notice anyone, other than the authors of the draft,
>clamoring for inclusion of the uniform model.  I did a like
>search in the DiffServ mailing list - which I already said
>something about in a different message - and found a similar
>silence from the throngs.
>
>This is the first draft in which the two models are discussed
>and it is also the draft on which we have been asked to give
>last call comments.  I stated that the Uniform model is not
>sufficiently well documented and should be removed.  You say
>it stays.
>
>Sounds perfectly reasonable to me.  You still need to address
>the issue that it is not sufficiently well documented.

I hop I could address those issues above.

>
>> 
>> I feel that PHP has been justified enough by the MPLS 
>> architecture document.
>
>Let's not pretend that I didn't say "the combination of 
>Uniform model and PHP".                  ===========
>              ===
>
>I am perfectly well aware that PHP is here to stay.  The
>combination of the Uniform model and PHP is a complexity
>that many may find difficult to swallow.  And, unlike PHP
>in general, it is a NEW complexity.
>
>> 
>> The reason we "attempt" to support uniform is that the 
>> group's agreed on the alias that it was useful.
>
>The group 'agreed' (mostly by its silence) that it would
>be useful to specify something about the Uniform model.
>You folks have made one attempt to do this and my comment
>is that it is either not enough, or too much.  See above.
>
>> >
>> >       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?
>
>How would you configure which function to apply for each
>specific LSP for which bandwidth might be signaled?  Will
>this be a global, per-interface or per-LSP parameter?  If
>it is supposed to be per-LSP, why bother with signaling?
>
>Can the signaled bandwidth be used for one purpose at one
>LSR along the LSP and another at another LSR?  This affects
>the scope of configuration since, if it is expected to be
>consistent, then it must be configured either per-LSP or
>globally within a DiffServ domain.
>
>Is the list of potential functions intended to be exhaustive?  
>If so, then it needs more entries.  If not, and the bandwidth 
>signaled is intended to be used consistently throughout an
>LSP, then what is the minimal set of possible functions that
>every LSP should support in order to achieve a useful level
>of interoperability?
>

As I mentioned in my previous email, we are not trying to address these
issues in this draft. The point we are trying to make is that contrary to
the CoS object which required to discard the BW information in RSVP
messages, we want to keep the door open and do not require to discard BW
information when Diffserv object is present. Since this is in conflict with
CoS object, we have tried to resolve the conflict by providing a table of
all possible combinations and outcomes.

>> 
>> >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.
>
>Okay by me.  It might be useful if there was a statement
>somewhere stating where these definitions can be found.
>Of course, if the answer is not simple, it might be easier
>to just include the definitions.  There are precedents
>among the other MPLS drafts.
>
>> 
>> 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
>> _________________________________________________________________ 
>> 
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 28 Jun 2000 13:19:50 -0700

Hi Eric,

Thanks for your comments. Here are my response:

>Sent: Tuesday, June 27, 2000 7:51 PM
>To: 'Shahram Davari'
>Cc: MPLS Mailing List (E-mail)
>	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."
>

Sure. It looks fine.

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

Sure. It looks fine.

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

Sure we will do that.

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

I have addressed this issue in my previous email. I hope you are convinced.

>> 
>> >
>> >	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 Francois has covered this.

>> 
>> >	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 think you have found now.

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

Fine.

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

Regards,
-Shahram