The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Two last calls (draft-ietf-mpls-diff-ext-06.txt)
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 >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: Thursday, July 27, 2000 9:49 AM >To: Francois Le Faucheur >Cc: Lou Berger; Francois Le Faucheur; Shahram Davari; mpls@UU.NET >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > >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 >>_________________________________________________________________ > |
|