The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

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:                  flefauch@cisco.com
>_________________________________________________________________
>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>_________________________________________________________________