Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

From: [email-masked]
Date: Tue, 12 Sep 2000 06:50:20 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF.

	Title		: Capability Negotiation: The RSVP CAP Object
	Author(s)	: S. Hamid
	Filename	: draft-ietf-issll-rsvp-cap-00.txt
	Pages		: 6
	Date		: 11-Sep-00
	
The DCLASS object is proposed in [DCLASS] to represent and carry 
Differentiated Services Code Points (DSCPs) within RSVP messages. The
principle use of the DCLASS object is to carry DSCP information
between a DS network and upstream nodes that may wish to mark packets
with DSCP values. A network element in the DS network determines the
value for DSCP which is further carried as a DCLASS object in RSVP 
RESV message to the sender host.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-issll-rsvp-cap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-issll-rsvp-cap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 12 Sep 2000 07:05:15 -0700

Hi,

To the author of this draft:

Nice draft, but I think you have completely mixed up the meanings of
upstream and downstream in your draft. In general the PATH message travels
from upstream to downstream and the RESV message travels from downstream to
upstream. In this draft sometimes this is true but in most cases it is
completely reversed. The way the draft is currently written is not readable.

Regards,
-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 6:50 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Integrated Services over Specific Link
Layers Working Group of the IETF.

Send a message to:
	[email-masked].
In the body type:

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 12 Sep 2000 10:28:27 -0400

May be some clarification of flow direction as follows is needed?
Sender and Receiver are with respect to the uni-directional packet flow.
Downstream = Sender towards Receiver.
Upstream = Receiver towards Sender.

Path Msg travels from Senders towards Receivers,
ResV Msg travels from Receivers towards Senders.

Maybe the use of "toward Receivers" and "toward Senders" is
more concise?

-- Kwok --

---

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Tue, 12 Sep 2000 16:14:50 -0500

Hi:

 I think the idea presented in the draft is a valid and logical response to
the issue of when to return DCLASS object to a 
PHOP node. I am not sure whether a whole "new" object needs to be defined to
carry the "marking capability" information
about the previous node. I suggest the following alternative implementation.

 There is a flag byte in the session object. Only one bit of that byte is
defined as E_Police bit to determine the effective edge 
for policing. If the host is capable of policing that session, it resets the
bit. Otherwise, it sets the bit and let the routers on
the path determines which router can police, and the first router that can
police resets the bit. 

 We can view this byte as a capability byte. We can argue to define one more
bit E_Mark bit to carry the marking capability
information.. 

SESSION OBJECT

	flags
		0x01 E_Police
		0x02 E_Mark 	A node sets this bit in the PATH message if
it is capable of marking the flow and requires 
                                    a DCLASS object in the RESV message. The
next hop RSVP node if finds the bit set, sends 
                                    the DCLASS object to the previous hop
node in the corresponding RESV message. A node 
                                    resets this bit in the PATH message if
it does not need the next hop node to return the 
                                    DCLASS object.

 This implementation not only saves from defining an object, but also
consistent with the E_Police bit. Similar to 
policing, the capablity to mark a flow is more meaningful on per session
basis. 

Cheers,
- Muhammad Jaseemuddin
  Nortelnetworks

---

From: Shahram Davari <[email-masked]>
Date: Wed, 13 Sep 2000 06:09:02 -0700

Sorry it was a mistype. You are correct. 

-Shahram

-----Original Message-----
From: John Wroclawski [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 6:32 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

At 1:48 PM -0700 9/12/00, Shahram Davari wrote:

>2) Usually upstream means from sender of data to receiver of data (note it
>is data not control)  and downstream means from receiver of data to sender
>of data.

Hi Shahram,

I would have said the opposite (i.e, data flows downstream). Did you 
mistype, or is there an issue?

John

---

From: "Hamid Syed" <[email-masked]>
Date: Wed, 20 Sep 2000 14:41:09 -0500

Thanx Shahram for your comments. Sorry for a late response. I was away for a
conference and did not have access to e-mails.

 First of all, my definition of upstream/downstream data flow could be
different from what the actual definition is (asyou pointed out) but in
terms of draft, i dont think there is inconsistency in the definition usage
at different places. I would appreciate if you can point me to the actual
locations where inconsistency is felt.

regards

Hamid Syed

> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Tuesday, September 12, 2000 4:49 PM
> To:	Chan, Kwok-Ho [BL60:470:EXCH]; Shahram Davari
> There are two separate issues:
> 
> 1) The draft is inconsistent in it uses of upstream and downstream words.
> In
> some parts of the draft upstream mean sender towards receiver, yet in some
> other part of the draft it means receiver toward sender.
> 
> The first issue is unacceptable, while the second issue is a definition
> only, and a different definition may be used if stated clearly.
> 
> Regards,
> -Shahram
> 
> 
> 
> From: Kwok-Ho Chan [mailto:[email-masked]]
> Sent: Tuesday, September 12, 2000 10:28 AM
> To: Shahram Davari

---

From: Shahram Davari <[email-masked]>
Date: Thu, 21 Sep 2000 07:41:27 -0700

Hi,
 
Here is an example from the abstract:
 
 1) The principle use of the DCLASS object is to carry DSCP information
   between a DS network and upstream nodes that may wish to mark packets
   with DSCP values.
 
 2) There may be situations where the sender host is not capable or may 
   not wish to mark the packets. Currently, there is no way for the 
   host or network devices to specify their capabilities to the upstream 
   nodes.

The first paragraph implies that  the host is upstream of the DS network,
while the
second paragraph implies that the DS network is upstream of the node.
 
Regards,
-Shahram

 -----Original Message-----
From: Hamid Syed [mailto:[email-masked]]
Sent: Wednesday, September 20, 2000 3:41 PM
To: 'Shahram Davari'; Kwok-Ho Chan; Shahram Davari
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

regards 

Hamid Syed 

	-----Original Message----- 
From:   Shahram Davari [SMTP:[email-masked]] 
Sent:   Tuesday, September 12, 2000 4:49 PM 
To:     Chan, Kwok-Ho [BL60:470:EXCH]; Shahram Davari 
Cc:     [email-masked] 
Subject:        RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt 

	1) The draft is inconsistent in it uses of upstream and downstream
words. In 
some parts of the draft upstream mean sender towards receiver, yet in some 
other part of the draft it means receiver toward sender. 

	2) Usually upstream means from sender of data to receiver of data
(note it 
is data not control)  and downstream means from receiver of data to sender 
of data. 

	The first issue is unacceptable, while the second issue is a
definition 
only, and a different definition may be used if stated clearly. 

	Regards, 
-Shahram 

	-----Original Message----- 
From: Kwok-Ho Chan [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, September 12, 2000 10:28 AM 
To: Shahram Davari 
Cc: [email-masked] 
Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt 

	-- Kwok -- 

>From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt>  
> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>