The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Last call comments
Hi Eric, Thanks for your comments. Here are my response: >-----Original Message----- >From: Eric Gray [mailto:EGray@zaffire.com] >Sent: Tuesday, June 27, 2000 7:51 PM >To: 'Shahram Davari' >Cc: MPLS Mailing List (E-mail) >Subject: RE: Last call comments > > >Shahram, > > 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> ... > >> >> > 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. > >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 |
|