The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

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