Subject: Status of COS Service in rsvp-lsp-tunnel-08.txt

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 05 Mar 2001 15:07:47 +0100

Hello,

This is a request for clarification regarding the use of the "Class of
Service" service in rsvp-lsp-tunnel-08.txt.
The motivation is to ensure that "diff-ext-xx.txt" is consistent with
"rsvp-lsp-tunnel-yy.txt".

As pointed out by David below, section 4.8 on COS Tspec and Flowspec (which
existed in rsvp-lsp-tunnel-07.txt) has been removed in
rsvp-lsp-tunnel-08.txt. However, the "COS service" is still mentioned in
the text (both section 2.3 and section 2.6 still refer to the removed
section 4.8). For instance:

"
Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-08.txt    February 2001

2.3. Service Classes

   This document does not restrict the type of Integrated Service
   requests for reservations.  However, an implementation SHOULD support
   the Controlled-Load service [4] and the Class-of-Service service, see
   Section 4.8.
"

Can you clarify what is the intended status re COS service:
	- was section 4.8 inadvertently removed?
	- was section 4.8 deliberately removed? Then:
		- what is the method to signal LSPs without bandwidth reservations? 
		- is there some text that I missed clarifying this?
		- should section 2.3 and section 2.6 then not be modified to remove
reference to 4.8?
	- am I looking at a version which is out-of-date?

BTW, the intent of diff-ext is simply to align with whatever is specified
in rsvp-lsp regarding signaling for LSP without reservations. The reason we
need to discuss it in diff-ext is that we need to clarify the relationship
of bandwidth reservations with the new "Diff-Serv" object.

Apologies if this has already been discussed on the alias. thanks for
pointing me to the relevant thread then.

Thanks

Francois

>Date: Fri, 02 Mar 2001 19:00:02 -0500
>From: David Charlap <[email-masked]>
>X-Mailer: Mozilla 4.76 [en] (WinNT; U)
>X-Accept-Language: en-US,en-GB,en
>To: [email-masked]
>Subject: Re: WG Last call
>Sender: [email-masked]
>
<clip>
>------------
>
>The second problem involves the use of this draft in conjunction with
>the latest changes to RSVP-TE (version -08).  Version -08 eleimates the
>COS service type from the TSPEC and FLOWSPEC objects.
>
>The DS draft requires that COS-type objects be used in order to signal
>an L-LSP without bandwidth reservations.  With the current revisions of
>these two drafts, this type of LSP can not be signalled at all.  It
>effectively makes it impossible to use RSVP-TE to signal a best-effort
>LSP (either E-LSP or L-LSP)
>
>Either the COS-type TSpec must be put back in RSVP-TE, or the DS draft
>must be updated to provide a means for singalling a best-effort LSP.
>
>-------------
<clip>

_________________________________________________________________
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, 05 Mar 2001 10:09:22 -0500

Francois, David,

         Here's my (limited) understanding of the issue.  A while back two 
separate ways of specifying BE/CoS service made it into drafts.  One of 
which was the CoS object in the rsvp-lsp draft.  The other, while I think 
came later in time, made it through the IETF process first and has been 
standardized in RFCs2997 and 2996.  This result was that the CoS object 
served the same purpose of an existing standards track RFC.   Having two 
ways to signal the same thing really doesn't make sense, and since they got 
there first,
we loose.  While the decision is painful now, I think it's better than the 
alternative.  Having some more words on this in draft certainly makes 
sense.  (Eric G. made this point privately.)

This is just my opinion and perspective...

Lou

---

From: David Charlap <[email-masked]>
Date: Mon, 05 Mar 2001 12:02:12 -0500

Lou Berger wrote:
> 
>          Here's my (limited) understanding of the issue.  A while back
> two separate ways of specifying BE/CoS service made it into drafts.
> One of which was the CoS object in the rsvp-lsp draft.  The other,
> while I think came later in time, made it through the IETF process
> first and has been standardized in RFCs2997 and 2996.  This result was
> that the CoS object served the same purpose of an existing standards
> track RFC.   Having two ways to signal the same thing really doesn't
> make sense, and since they got there first, we loose.  While the
> decision is painful now, I think it's better than the alternative.
> Having some more words on this in draft certainly makes sense.  (Eric
> G. made this point privately.)

Thanks.  RFC 2997 allows RSVP to signal best-effor without using
DiffServ extensions.  Replacing support for COS with Null-IntServ will
be a bit annoying in places, but not nearly as difficult as implementing
the diff-ext draft.

Which working group developed 2997?  I don't remember seeing anything
about it here or on the RSVP list.  (Maybe it was on the IntServ list? 
I'm not subscribed to that one.)

With respect to the MPLS drafts (RSVP-TE and diff-ext), these RFCs
should definitely be referenced, since they appear to have become hard
requirements.

-- David

---

From: George Swallow <[email-masked]>
Date: Mon, 05 Mar 2001 11:39:04 -0500

Francois -

My error on the dangling references.  I'll issue an updated draft with
pointers to the "Null Service Type", RFC 2997.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 8 Mar 2001 17:03:01 -0500 (EST)

To add a small point, it would be helpful to add a section at the
beginning stating what changed since the last version of the draft. That
way everyone is aware of the changes right away.

Thanks,
-arthi