Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)

From: Shahram Davari <[email-masked]>
Date: Fri, 21 Jul 2000 08:58:58 -0700

Lou, George,

Section 5.6 of the draft focuses ONLY on the Diffserv LSRs. It requires the
Diffserv LSRs to ignore the COS field and just use it as an indication of
not  reserving BW. 

But this doesn't preclude the use of COS field by non-Diffserv LSRs.
Therefore you could still have non Diffserv LSRs in the same network and you
can use the COS field for their non-Diffserv behavior. However, this is up
to the network operator to make sure that a non-Diffserv LSP spans only
non-Diffserv routers.

So in summary this draft is not addressing non-Diffserv LSRs, and does not
preclude the use of them, provided LSPs are setup properly.

Regards,
-Shahram

>-----Original Message-----
>From: Lou Berger [mailto:[email-masked]]
>Sent: Friday, July 21, 2000 8:39 AM
>To: George Swallow
>Cc: [email-masked]
>Subject: Re: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
>
>
>George,
>         I still believe the draft doesn't cover the cases 
>where there are 
>non-DS and DS LSRs in the same network.  I raised this issue 
>in February, 
>see list archive for 2/8 - 2/10, and briefly at the last WG 
>session.  My 
>understanding from the authors was that they just didn't 
>belive this case 
>was valid and therefore didn't need to be addressed in the 
>draft.  Given 
>that draft-lefaucheur-diff-te-reqts-00.txt raises the same issue (in 
>section 3), I think the diff-ext draft should be fixed to 
>allow for non-DS 
>and DS LSRs in the same network.
>
>Lou
>
>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.
>
>At 12:08 PM 7/19/00 -0400, George Swallow wrote:
>>This message begins a last calls on:
>>
>>   draft-ietf-mpls-diff-ext-06.txt and
>>   draft-ietf-mpls-rsvp-lsp-tunnel-06.txt
>>
>>The last calls will end on July 26 midnight GMT.  Comment are limited
>>to the deltas between these and their respective prior drafts.
>>
>>With regard to the RSVP-TE draft, the recent comments to the list are
>>accepted as last call comments and need not be repeated.
>>
>>...George
>>
>>======================================================================
>>George Swallow       Cisco Systems                   (978) 244-8143
>>                      250 Apollo Drive
>>                      Chelmsford, Ma 01824
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 21 Jul 2000 09:31:40 -0700

Hi Lou, George

>does use a new object that could just be merged with the 

Your solution is ONLY valid if a single LSR could be both a Diffserv LSR and
a non-Diffserv LSR. 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.

Regards,
-Shahram

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Jul 2000 12:36:47 -0400

Shahram,
         I thing the issue is the case where an LSP spans DS and non-DS LSRs.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Jul 2000 12:59:04 -0400

Shahram,
         see below.

At 09:31 AM 7/21/00 -0700, Shahram Davari wrote:
>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

We covered this the last time around.  Here's a relevant excerpt:

>Date: Wed, 09 Feb 2000 16:57:57 -0500
>To: Shahram Davari <[email-masked]>
>From: Lou Berger <[email-masked]>
>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt
>Cc: "'Lou Berger'" <[email-masked]>, "'Jim Boyle'" <[email-masked]>,
>         [email-masked]
>Sender: [email-masked]
>[...]

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

---

From: Shahram Davari <[email-masked]>
Date: Fri, 21 Jul 2000 11:52:32 -0700

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

>Sent: Friday, July 21, 2000 12:59 PM
>To: Shahram Davari
>Cc: 'Lou Berger'; George Swallow; [email-masked]
>Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)
>
>
>Shahram,
>         see below.
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Jul 2000 14:58:53 -0400

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

---

From: Shahram Davari <[email-masked]>
Date: Fri, 21 Jul 2000 12:13:11 -0700

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

>Sent: Friday, July 21, 2000 2:59 PM
>To: Shahram Davari
>Cc: 'Lou Berger'; Shahram Davari; George Swallow; [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Fri, 21 Jul 2000 12:24:24 -0700

Hi all,

Just as a classifier, what Lou Berger is referring to as "non-Diffserv LSR"
is an LSR that does support differentiated queuing and scheduling (as
indicated by some COS field) just it doesn't interpret the MPLS header's EXP
bits in the current MPLS-diffserv manner. He is NOT referring to an LSR that
is incapable of providing differentiated queuing and scheduling to packets .

Regards,

Shahram

Shahram Davari
Systems Engineer
Product Research
PMC-Sierra, Inc. (Ottawa) 
555 Legget drive,
Suit 834, Tower B,
Ottawa, ON K2K 2X3, Canada
Phone: +1 (613) 271-4018
Fax  : +1 (613) 271-7007

---

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Jul 2000 08:09:46 -0700

Hi Lou,

I like Francois' proposal. Your proposal forces all the new Diffserv-LSR
boxes to implement pre-Diff-ext (non-DS) mechanisms (which is obsolete).
This will cause the pre-Diff-ext mechanisms which are non standard, to drag
for ever, even after all the LSRs in the world are using Diffserv.

I think Francois' proposal fulfills your concern. Because some vendors may
opt to implement both DS and non-DS in their boxes (LSRs), and those
operators that are concerned with upgrading their existing non-DS equipment
could buy them, while some other vendors may just implement DS LSRs, and the
operators that didn't have non-DS LSRs will buy them and won't pay extra for
something that they don't need.

Francois' proposal also gives the non-DS operators an option of upgrading
all their LERs to the (DS + non-DS) LERs, and after they have done so they
don't need to upgrade their core LSRs to (DS+ non-DS), rather they could
upgrade their core LSRs directly to DS LSRs and as I mentioned in my last
email this would work perfectly because the LERs could set both EXP and COS
field. The EXP could be used by DS-LSRs and the COS could be used by non-DS
LSRs.

Regards,
-Shahram 

>Sent: Thursday, July 27, 2000 9:49 AM
>To: Francois Le Faucheur
>Cc: Lou Berger; Francois Le Faucheur; Shahram Davari; [email-masked]
>Francois,
>At 05:45 PM 7/26/00 +0200, Francois Le Faucheur wrote:
>>Lou,
>>
>>At 12:04 24/07/2000 -0400, Lou Berger wrote:
>>
>> >
>> >How about including an "SHOULD" level option that allows a 
>MPLS-DS LSR to
>> >treat LSPs signaled without the DIFFSERV object as non-DS 
>LSPs?  I think
>> >this would address this issue.
>> >
>>
>>Just to be sure I understand the proposal:
>>The text would say that when there is RSVP signaling without 
>the Diff-Serv 
>>object, the LSR SHOULD (instead of MUST) interpret this as a 
>request for 
>>an "E-LSP using Preconfigured EXP<-->PHB Mapping".
>>(which would imply that if there's a really good reason to do 
>otherwise - 
>>eg. to maintain some pre-Diff-Ext QoS support - then you could do so).
>>
>>If that's the proposal, that works for me.
>
>On additional recommendation and we're there. Something like:
>An implementation SHOULD include an option that overrides 
>this.  When this 
>"override option" is set, the LSR then treats LSPs signaled 
>without the 
>DiffServ object as standard, non-DS, LSPs.
>
>How does something like this sound?
>
>> >(BTW which heterogeneity and transition issues are you 
>addressing with the
>> >objects proposed in your new draft?)
>> >
>>
>>The new draft focuses on Diff-Serv-aware Traffic Engineering whereby 
>>different bandwidth constraints can be applied to different Diff-Serv 
>>Classes. This involves advertising more than one "unreserved 
>bandwidth" 
>>information in IGPs and using the appropriate one for path 
>computation for 
>>each Diff-Serv Class. Also, it involves performing admission 
>control over 
>>different bandwidth pools at LSP set-up.
>>The transition situation we focused on is when migrating from 
>existing TE 
>>(which we refer to as "Aggregate TE") to "Diff-Serv-awrae-TE". More 
>>precisely , the migration situation involves a mix of:
>>         - "old" LSRs which are Diff-Serv capable and (Aggregate) TE 
>> capable (ie support a single bandwidth constraint, aka 
>single bandwidth 
>> pool, aka compute the same route regardless of the Diff-Serv 
>Class transported)
>>         - "new" LSRs which are Diff-Serv capable and 
>Diff-Serv-aware-TE 
>> capable (ie support a multiple bandwidth constraints, aka multiple 
>> bandwidth pools, aka may compute different routes depending on the 
>> Diff-Serv Class transported).
>>
>>Note that we are not proposing new objects just to address 
>this transition 
>>issue. Rather we are saying that the new objects/procedures that get 
>>defined for Diff-Serv-aware-TE MUST satisfy this migration goal.
>>
>>Hope that clarifies
>
>Sounds like parallel issues to me.  But it doesn't matter as 
>long as we 
>agree on the above recommendations, i.e., I think we have a 
>compromise that 
>covers
>the open issue.
>
>Thanks,
>Lou
>
>>thanks
>>
>>Francois
>>
>> >Thanks,
>> >Lou
>>_________________________________________________________________
>>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:                  [email-masked]
>>_________________________________________________________________
>>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
>Valbonne - France
>>_________________________________________________________________
>