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

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

Shahram,
         See below.

At 12:13 PM 7/21/00 -0700, Shahram Davari wrote:
>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.

More precisely the edge LSR doesn't do MPLS DS, it may do IP DS.

>I don't think your assumption that the edge LSR of a Diffserv network being
>a non-Diffserv LSR is a valid assumption.

Right, we disagree.

>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.

Again, I think the issues here are mainly related to transition.  I think 
the following from draft-lefaucheur-diff-te-reqts-00.txt captures the issue.
    We identify the following backward compatibility requirements for
    the RSVP/CR-LDP extensions:
      - operations in heterogeneous environments need to be supported
        for smooth migration, where some LSRs are Diff-Serv-TE-capable
        (as defined in this specification) while some other LSRs are not
        Diff-Serv-TE-capable (i.e. support (aggregate) TE only)
and
      - in heterogeneous environments, the solution needs to ensure that
        a non-Diff-Serv-TE-capable LSR would reject establishment of a
        Class-Type N (N=1,2,3) LSP.

Note that the latter issue isn't addressed by your example but is in my 
proposal.

Lou

>Regards,
>-Shahram
>
>
> >-----Original Message-----
> >From: Lou Berger [mailto:[email-masked]]
> >Sent: Friday, July 21, 2000 2:59 PM
> >To: Shahram Davari
> >Cc: 'Lou Berger'; Shahram Davari; George Swallow; [email-masked]
> >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:[email-masked]]
> >> >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.
> >> >
> >> >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 <[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
> >> >
> >> >>Regards,
> >> >>-Shahram
> >> >
> >

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 24 Jul 2000 17:19:24 +0200

Lou,

>Note that the latter issue isn't addressed by your example but is in my 

As Shahram pointed out earlier, your transition concern does not relate to "non-Diff-Serv LSRs" (non-DS-LSRs) , but rather relate to "LSRs which are Diff-Serv capable but do so in a pre-Diff-Ext manner i.e. use non-zero-COS signaling". The question we are facing here is about backward compatibility with a pre-Diff-Ext method to support Diff-Serv, not with devices which did not support DS. So, the backward compatibility requirements you quote for non-DS-capable nodes don't directly relate to this particular migration issue.

My view is that:
	- clearly, the COS Service defined in rsvp-te is essential so that LSPs can be signaled without bandwidth reservation.
	- However, the use of non-zero COS field in the COS Flow_Spec/Sender_Tspec for support of Diff-Serv is pretty much superseeded by the Diff-ext specification. 
	- the ability to allow introduction of Diff-Serv without changing anything in the signaling (ie use Preconfigured mapping E-LSPs) simplifies migration from true-non-DS-LSRs to Diff-Serv operations, which is the most important migration scenario. So this should be retained.

Cheers

Francois

>> >> >>you view this as acceptable?

_________________________________________________________________
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
_________________________________________________________________

---

From: Lou Berger <[email-masked]>
Date: Mon, 24 Jul 2000 12:04:13 -0400

Francois,

At 05:19 PM 7/24/00 +0200, Francois Le Faucheur wrote:
>As Shahram pointed out earlier, your transition concern does not relate to 
>"non-Diff-Serv LSRs" (non-DS-LSRs) , but rather relate to "LSRs which are 
>Diff-Serv capable but do so in a pre-Diff-Ext manner i.e. use non-zero-COS 
>signaling".

This was just one example.  I think the real issues is with LSRs that are 
providing different classes of LSPs using the CoS/QoS semantics (defined 
elsewhere) loosing service as those LSPs transit MPLS-DS nodes.  This 
includes both LSRs that know nothing of DS and those that have only a 
limited knowledge of DS.

>  The question we are facing here is about backward compatibility with a 
> pre-Diff-Ext method to support Diff-Serv, not with devices which did not 
> support DS. So, the backward compatibility requirements you quote for 
> non-DS-capable nodes don't directly relate to this particular migration issue.

This is a special case, not the general one.  If you'd like to take this 
special case off the table, that's fine with me. When/if we address the 
general case, I expect this special case will be taken care of as well.

>My view is that:
>         - clearly, the COS Service defined in rsvp-te is essential so 
> that LSPs can be signaled without bandwidth reservation.
>         - However, the use of non-zero COS field in the COS 
> Flow_Spec/Sender_Tspec for support of Diff-Serv is pretty much 
> superseeded by the Diff-ext specification.

No argument.  The main issue for this case is transition.

>         - the ability to allow introduction of Diff-Serv without changing 
> anything in the signaling (ie use Preconfigured mapping E-LSPs) 
> simplifies migration from true-non-DS-LSRs to Diff-Serv operations, which 
> is the most important migration scenario. So this should be retained.

I like the concept, the only problem is that as I understand the document, 
service will be degraded in the case where CoS/CL/GS is being signaled by a 
non-DS LER when the EXP bits are not set according to the preconfigured EXP 
map.

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.

(BTW which heterogeneity and transition issues are you addressing with the 
objects proposed in your new draft?)

Thanks,
Lou

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 26 Jul 2000 17:45:23 +0200

Lou,

>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.

>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

thanks

Francois

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Jul 2000 09:49:29 -0400

Francois,

At 05:45 PM 7/26/00 +0200, Francois Le Faucheur wrote:
>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).
>

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?

>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

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 27 Jul 2000 17:16:50 +0200

Lou,

>How does something like this sound?

But what exactly is a "standard, non-DS, LSP"?:
	- an LSP which has no QoS?
	- an LSP which has an Int-Serv CL/GS service. And then, are EXP bits igored?
	- an LSP which has some Diff-SErv service based on a non-zero-COS-field as per the scenario you mentioned earlier? And then , are EXP bits ignored?
	- any of the above?
My perception is that this is quite open and we shouldn't have to worry about it in the Diff-SErv spec. We have agreed on an "escape code" above (the first "SHOULD") which allows one to maintain whatever flavor of "standard, non-DS, LSP" he/she liked. I think this is all the Diff-Serv spec probably needs to say and would prefer to avoid having to mention in any way QoS support which were pre-Diff-Ext. So I'd like to leave out the new recommendation.

In any case, if a statement about Override option was to be included, I would argue that it should be a MAY and not a MUST. I think it is quite reasonable for a new implementation supporting MPLS Diff-SErv "a la" Diff-Ext to not worry about pre-Diff-Ext stuff.

Thanks

FRancois

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Jul 2000 18:39:46 -0400

Francois,
         See below.
At 05:16 PM 7/27/00 +0200, Francois Le Faucheur wrote:
>         - an LSP which has some Diff-SErv service based on a 
> non-zero-COS-field as per the scenario you mentioned earlier? And then , 
> are EXP bits ignored?
>         - any of the above?

One that supports the service defined in mpls-rsvp-lsp-tunnel or GS/CL, and 
sure EXP bits may be ignored.

>My perception is that this is quite open and we shouldn't have to worry 
>about it in the Diff-SErv spec.

I think diff serv has always been concerned about preserving non-DS service.

>We have agreed on an "escape code" above (the first "SHOULD") which allows 
>one to maintain whatever flavor of "standard, non-DS, LSP" he/she liked. I 
>think this is all the Diff-Serv spec probably needs to say and would 
>prefer to avoid having to mention in any way QoS support which were 
>pre-Diff-Ext. So I'd like to leave out the new recommendation.
>
>In any case, if a statement about Override option was to be included, I 
>would argue that it should be a MAY and not a MUST.

I believe I said "SHOULD" not MUST.  I'd be fine with a MAY.

>I think it is quite reasonable for a new implementation supporting MPLS 
>Diff-SErv "a la" Diff-Ext to not worry about pre-Diff-Ext stuff.

I disagree.  Not all routers will be DS capable and we shouldn't break the 
service that they  request via valid (not deprecated) mechanisms.

Thanks,
Lou