The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Last call comments
Eric, Thanks for your comments. Here are some answers: >-----Original Message----- >From: Eric Gray [mailto:EGray@zaffire.com] >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: flefauch@cisco.com >> _________________________________________________________________ >> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 >> Valbonne - France >> _________________________________________________________________ >> > |
|