The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

Francois,
         See below.
At 05:16 PM 7/27/00 +0200, Francois Le Faucheur wrote:
>Lou,
>
>At 09:49 27/07/2000 -0400, Lou Berger wrote:
> >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?
> >
>
>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?

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


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