The MPLS WG Archive

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

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
>