The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Two last calls (draft-ietf-mpls-diff-ext-06.txt)
Lou, What you are saying is that, you want an LSP to span both Diffserv and non-Diffserv LSRs, but you don't want to use Diffserv edge LSR. I don't think your assumption that the edge LSR of a Diffserv network being a non-Diffserv LSR is a valid assumption. Therefore I don't think anybody can argue about the fact that : If you have Diffserv nodes in the network, the edge routers must support Diffserv. Regards, -Shahram >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: Friday, July 21, 2000 2:59 PM >To: Shahram Davari >Cc: 'Lou Berger'; Shahram Davari; George Swallow; mpls@UU.NET >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > >Your example looks fine. > >Now consider the case where the ingress/LER doesn't support >MPLS DS. It >uses COS1, and sets the EXP bit to 000. The LSR1 will treat >the packets >with EXP0, probably DF, while LSR2 will provide COS1 service. > >So the introduction of a DS capable transit node can reduce >the service >seen by an existing non-DS edge. This is the problem. > >Lou > > >At 11:52 AM 7/21/00 -0700, Shahram Davari wrote: >>Lou, >> >>Let me explain my solution to your problem with an example. >Assume we have >>an LSP that spans LSR1 (Diffserv LSR) and LSR2 (non-Diffserv LSR). Now >>assume that in the RSVP message we set COS=COS1 and no >Diffserv object. >>Since the LSP is spanning a Diffserv LSR and a non-Diffserv >LSR, the LER >>(Label Edge Router) must be a Diffserv and a non-Diffserv >edge LSR. Now >>assume that the LER sets the EXP field of all packets to EXP=EXP1 >>(indicating a local PHB) in such a way that both EXP1 and >COS1 indicate the >>same local behavior to the LSR1 and LSR2 respectively: >> >> >> EXP=EXP1 COS=COS1 >> O----------O----------O------ >> LER LSR1 LSR2 >> >> >>LSR1 will ignore the COS field and will behave according to >pre-configured >>behavior of EXP1, and LSR2 will ignore the EXP field and >behave according to >>COS1. Since we have designed the EXP1 and COS1 behaviors to >be the same, >>then we will have a consistent behavior throughout the LSP. >> >>If the LER sets the EXP to a wrong value (i.e., a value that >does not match >>COS1), then this is a configuration problem, which pretty >much exist in all >>Diffserv networks. >> >>Does this make sense? >> >>Regards, >>-Shahram >> >> >-----Original Message----- >> >From: Lou Berger [mailto:lberger@labn.net] >> >Sent: Friday, July 21, 2000 12:59 PM >> >To: Shahram Davari >> >Cc: 'Lou Berger'; George Swallow; mpls@UU.NET >> >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) >> > >> > >> >Shahram, >> > see below. >> > >> >At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: >> >>Hi Lou, George >> >> >> >> >PS As mentioned back on 2/8, I believe one trivial solution is >> >> >to require >> >> >the use of the DiffServ Object/TLV for all E-LSPs, where use of >> >> >preconfigured EXP<-->PHB mappings is indicated by either (pick >> >> >one) no map >> >> >parameters or a single map parameter set to all zeros. >> >> >Another solution is >> >> >to use the one proposed in >> >> >draft-lefaucheur-diff-te-ext-00.txt, although it >> >> >does use a new object that could just be merged with the >> >> >DiffServ Object. >> >> >> >>Your solution is ONLY valid if a single LSR could be both a >> >Diffserv LSR and >> >>a non-Diffserv LSR. >> > >> >It works for both cases, i.e., for the cases where a DS LSR >> >can support >> >non-DS LSPs and when it cannot. In the latter case, a >PathErr with an >> >appropriate code&value would need to be generated. >> > >> >>So it could use the presence of Diffserv object to >> >>decide what behavior it should have (Diffserv behavior or >non-Diffserv >> >>behavior).I don't see any benefit in having a single LSR >to be both a >> >>Diffserv LSR and a non-Diffserv LSR. If the purpose is to >support both >> >>standardized PHBs and some local behavior that are not >> >standardized, you >> >>could always use the Diffserv local-PHBs. >> > >> >We covered this the last time around. Here's a relevant excerpt: >> > >> > >> >>Date: Wed, 09 Feb 2000 16:57:57 -0500 >> >>To: Shahram Davari <Shahram_Davari@pmc-sierra.com> >> >>From: Lou Berger <lberger@labn.net> >> >>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt >> >>Cc: "'Lou Berger'" <lberger@labn.net>, "'Jim Boyle'" >> ><jboyle@Level3.net>, >> >> mpls@UU.NET >> >>Sender: owner-mpls@UU.NET >> >>[...] >> > >> >LB: >> > >> > >> >>> > >> >>> > One (new) point, your implicit mode hijacks existing >> >>> > signaling mechanisms >> >>> > and gives them new meaning. (Now that I think of it, this is >> >>> > a large part >> >>> > of my objection to the current form of the draft.) For >> >>> > non-DS nodes, CoS >> >>> > behavior can be provided by signaling a CoS LSP and not using >> >>> > the EXP bits >> >>> > at all. If that same LSP hits a DS node with the current >> >>> > draft, it will be >> >>> > treated as an E-LSP and the matching traffic will receive the >> >>> > service that >> >>> > matches bits 000. >> > >> >SD: >> > >> >>>First of all you have the same situation in a non-MPLS and >> >Diffserv network. >> >>>Do you plan to add signaling to them too? >> > >> >LB: >> > >> >>No because all traffic is best-effort in a DS network. There >> >would be >> >>some work to resolve conflicts if you were trying to support >> >RSVP on the >> >>same links/data as DS. >> > >> >SD: >> > >> >>>Secondly it is a misconfiguration to use a non-DS node in a >> >Diffserv network >> >>>and it is very unusual to use a DS-node in a Diffserv >> >network that supports >> >>>non-Diffserv behavior too. So why don't we choose the >> >DS-behavior to be a >> >>>default behavior in a Diffserv network, and use another >> >object for signaling >> >>>those rare non-DS LSPs? >> > >> >LB: >> > >> >>So you're suggesting a new object/TLV that says "I'm not >> >diff-serv" rather >> >>than have the new feature say "I'm diff-serv"? I don't get >> >it. We're >> >>talking about few bytes of overhead that you've already >> >defined and are >> >>willing to incur for all L-LSPs and some E-LSPs. We're not >> >talking about >> >>any substantive change in processing or state. >> > >> >SD: >> > >> >>>Remember the only situation that you would use a configured >> >E-LSP is when >> >>>you are sure that all your nodes are configured and can >> >support the required >> >>>PHBs. >> > >> >LB: >> > >> >>this is not correct. With the current definition, as soon as you >> >>configure a node to be a DS node, all established LSPs are >> >E-LSPs or L-LSPs. >> >> >> >>Albeit a corner case for non-green field networks, I think you're >> >>requiring the configuration of all your nodes at the same >> >moment of time >> >>or just not caring about the traffic service levels during >> >reconfig. Do >> >>you view this as acceptable? >> >> >> >>Lou >> > >> >That's it. >> > >> >Lou >> > >> >>Regards, >> >>-Shahram >> > >
|
|