Subject: Proposed MS-PW "QoS" Requirements Clarifications

From: David McDysan <[email-masked]>
Date: Fri, 25 Mar 2005 09:53:15 -0500

Richard,

I agree with the sentiment of your comment. Here are a few specific
proposals on changing section 6.3
draft-martini-pwe3-mh-pw-requirements-01.txt with the intent of clarifying
the requirements:

I made a comment similar to the following on 1/19/05 and that has not been
addressed in the -01 requirements draft:

The current requirement on traffic parameters is much too general. There
needs to be standard on how to signal the requested Quantity of Service
(QoS) (i.e.,  traffic parameters (e.g., the average rate, burst duration and
peak rate from RFC 2215, the FR style parameters from
draft-shah-pwe3-pw-qos-signaling-02.txt, or the SRTCM or DRTCM from RFCs
2697 and 2698, respectively).  A number of these traffic parameter specs do
have an equivalence for cerating 

The requirements also need to precisely specify how the Quality of Service
(QoS) characteristics are signaled. The current requirement is too general.
There must also be some reference for the defintion of "QoS Class." Possible
references are a minimal set of Diffserv PHBs and the associated semantics
from Baker/Babriaz being discussed in tsvwg or the effort in the ITU-T
updating Y.1540 and Y.1541.  

Gerry Ash pointed out NSIS-based QoS-NSLP signaling for Y.1541 QoS classes
that could also be relevant, see
http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt.

I pointed this out again on 2/9/05 and also made the following comment based
upon reading the above draft.

Signaling the accumulated QoS parameter (latency, latency variation, loss,
etc.) is more general, yet more complex. The use of certain class or service
(CoS) (e.g., Y.1541) implicitly assumes a reference configuration, which may
or may not be appropriate. If this CoS method is used, the protocol SHOULD
track the domains traversed so that it could be mapped against the reference
model.

Suggest that both methods: accumulate QoS parms and use CoS be mentioned in
the next version. 

Also, I recommend that specifics on Quality of Service metrics and
measurement methods be added. The ietf ippm working group has produced a
number of documents in this area that should be referenced.

Does anyone object to adding the above more specific requirements and cited
references to the pwe3 wg document that will be based upon
draft-martini-pwe3-mh-pw-requirements-01.txt?

Thanks,

Dave 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, March 25, 2005 3:48 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
> 
> I really can't understand why there is speculation over the 
> agreement of requirements in the requirements draft (which 
> has been accepted as a WG document). The MS-PW requirements 
> draft is a joint effort between a number of tier 1 service 
> providers. Every requirement has been submitted by one of the 
> contributing providers, and I would assume that each of the 
> requirements is based on current/planned network deployments 
> and associated network design goals - I do not think the 
> contributing authors would waste their time submitting 
> requirements otherwise.
>  
> There may be requirements that are still missing, 
> particulalry from providers that have not yet contributed to 
> the draft. Some of the requirements included in the draft may 
> need further explanation, and the draft itself may need 
> further work to tidy it up (i.e. remove duplication, improve 
> readability). Also, over time some of the requirements may 
> change as new solutions/services become available and 
> networks evolve. However, the current draft describes the 
> MS-PW requirements as perceived by the contributing tier 1 
> service providers today, and these requirements will not 
> change significantly in the short term.
>  
> Therefore, for the purposes of MS-PW discussions, these 
> requirements should be accepted as the definitive MS-PW 
> requirements regardless of what stage in the IETF 
> standardisation process the requirements draft is at.
>  
> Regards,
> Richard
> 
> 	-----Original Message----- 
> 	From: [email-masked] on behalf of Gray, Eric 
> 	Sent: Thu 24/03/2005 16:14 
> 	To: Bruce Davie 
> 	Cc: 'Kireeti Kompella'; [email-masked] 
> 	Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
> 	
> 	
> 
> 	Bruce,
> 	
> 	        You left out the obvious point at which we might
> 	"have [requirements]" - when there are customers who
> 	say they would like to have it...  :-)
> 	
> 	--
> 	Eric
> 	
> 	-----Original Message-----
> 	From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> 	Kireeti Kompella
> 	Sent: Thursday, March 24, 2005 3:45 PM
> 	To: Bruce Davie
> 	Cc: [email-masked]
> 	Subject: Re: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
> 	
> 	
> 	On Wed, 23 Mar 2005, Bruce Davie wrote:
> 	
> 	> --On Wednesday, March 23, 2005 11:48 AM -0800 Kireeti Kompella
> 	> <[email-masked]> wrote:
> 	>
> 	> > On Wed, 23 Mar 2005, Bruce Davie wrote:
> 	...
> 	> I haven't passed judgment on RSVP. It certainly seems 
> premature to start
> 	> increasing the number of protocols for PWs before we 
> agree on the
> 	> requirements.
> 	
> 	Good to hear that.
> 	
> 	However (believe it or not), the authors didn't propose 
> the above
> 	document solely for the purpose of increasing the number of PW
> 	protocols.  Thay have what they believe are sound technical and
> 	pragmatic reasons.
> 	
> 	> > For that matter, it's not like we have a single PW 
> protocol.  The
> 	> > "unhelpful" event already occurred, for better or 
> worse.  Now we
> 	> > should focus on what's the most suitable protocol 
> for the reqts.
> 	>
> 	> Once we have the reqts, I agree.
> 	
> 	When do we "have the reqts"?  When:
> 	a) it's a WG doc?
> 	b) it's in WG Last Call?
> 	c) it's in IETF Last Call?
> 	d) it's an RFC?
> 	
> 	> I chose my words carefully. By saying "at this time" 
> I do indeed
> 	> mean that, when we have a better sense of the 
> requirements, it would
> 	> be a good time to decide which protocol(s) the 
> working group will
> 	> adopt to meet them.
> 	
> 	Same question as above: when can we say that we have a 
> better sense of
> 	the requirements?
> 	
> 	Kireeti.
> 	-------
> 	
> 	_______________________________________________
> 	pwe3 mailing list
> 	[email-masked]
> 	https://www1.ietf.org/mailman/listinfo/pwe3
> 	
> 	_______________________________________________
> 	pwe3 mailing list
> 	[email-masked]
> 	https://www1.ietf.org/mailman/listinfo/pwe3
> 	
> 
>

---

From: Ted Seely <[email-masked]>
Date: Fri, 25 Mar 2005 11:18:09 -0500 (EST)

i'm curious, is there a summary of the requirements as pointed out below:

"the current draft describes the MS-PW requirements as perceived by the
contributing tier 1 service providers today"?

On Fri, 25 Mar 2005 [email-masked] wrote:

> I really can't understand why there is speculation over the agreement
> of requirements in the requirements draft (which has been accepted as
> a WG document). The MS-PW requirements draft is a joint effort between
> a number of tier 1 service providers. Every requirement has been
> submitted by one of the contributing providers, and I would assume
> that each of the requirements is based on current/planned network
> deployments and associated network design goals - I do not think the
> contributing authors would waste their time submitting requirements
> otherwise.
>  There may be requirements that are still missing, particulalry from
> providers that have not yet contributed to the draft. Some of the
> requirements included in the draft may need further explanation, and
> the draft itself may need further work to tidy it up (i.e. remove
> duplication, improve readability). Also, over time some of the
> requirements may change as new solutions/services become available and
> networks evolve. However, the current draft describes the MS-PW
> requirements as perceived by the contributing tier 1 service
> today, and these requirements will not change significantly in the
> short term.
>  Therefore, for the purposes of MS-PW discussions, these requirements
> should be accepted as the definitive MS-PW requirements regardless of
> what stage in the IETF standardisation process the requirements draft
> is at.

>  Regards, Richard
> 	From: [email-masked] [mailto:[email-masked]]On Behalf Of
> 	Kireeti Kompella
> 	> I haven't passed judgment on RSVP. It certainly seems premature to start
> 	> increasing the number of protocols for PWs before we agree on the
> 	> requirements.
>
> 	Good to hear that.
>
> 	However (believe it or not), the authors didn't propose the above
> 	> > For that matter, it's not like we have a single PW protocol.  The
> 	> > "unhelpful" event already occurred, for better or worse.  Now we
> 	> > should focus on what's the most suitable protocol for the reqts.
> 	>
> 	> I chose my words carefully. By saying "at this time" I do indeed
> 	> mean that, when we have a better sense of the requirements, it would
> 	> be a good time to decide which protocol(s) the working group will
> 	> adopt to meet them.
>
> 	Same question as above: when can we say that we have a better sense of
> 	the requirements?
>
> 	Kireeti.
> 	-------
>

Ted Seely
Principal Network Design Engineer
Internet Engineering - SprintLink
(W) 703.689.6425
(M) 703.967.3289
AIM - wanpro00
Yahoo IM - tseely01

There are no such things as friends in this industry.