Subject: Re: [PWE3] RE: Proposed MS-PW "QoS" Requirements Clarifications

From: Eric Rosen <[email-masked]>
Date: Fri, 01 Apr 2005 11:24:28 -0500

Richard> Dave,  Regarding your suggestion  to carry  parameters such  as the
Richard> average rate, burst duration and  peak rate, and your references to
Richard> RFC2697/RFC2698,  I  assume  that  this  is to  support  per  MS-PW
Richard> policing/queuing at S-PEs?  

I  thought it  was  more to  enable mapping  of  the PEs  to appropriate  TE
tunnels. 

Richard> One case where per MS-PW policing will be needed is at border S-PEs
Richard> where  a  provider  may   not  trust  another  provider  to  police
Richard> individual MS-PWs correctly

I'm  not sure  I understand  why  per-PW policing  is needed  at the  second
provider, as opposed to some sort  of aggregate policing.  Then if the first
provider  is not  policing  properly,  the enduser  service  might not  work
properly, but  presumably that's the fault  of the first  provider, and it's
the first provider who has direct contact with the enduser anyway. 

If you really want per-PW policing and shaping at each S-PE, then the proper
model may  be that  each segment looks  like an  access circuit to  the next
segment.  That might  turn out to be very different than  the model in which
the S-PE points are transparent to the data plane.

Richard> One case  where per MS-PW queues (and  associated traffic counters)
Richard> could  be  used  is at  border  S-PEs  to  obtain per  MS-PW  usage
Richard> information in order to support usage based inter-provider charging
Richard> models.

Support for this  charging model requires per PW  usage information, but not
per-PW queues. 

But  do you really  plan to  have per-pseudowire  usage-based inter-provider
billing? 

Richard> different providers  will offer different class  of service options
Richard> with varying traffic characteristics,  and therefore it may be very
Richard> difficult  or not  possible  to map  class  of service  definitions
Richard> between providers 

In which case there would not be much point in signaling QoS parameters. 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: David McDysan <[email-masked]>
Date: Thu, 28 Apr 2005 12:19:34 -0400

Richard,

A few responses in line below.

Dave 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, March 31, 2005 2:43 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Proposed MS-PW "QoS" Requirements Clarifications
> 
> Dave,
>  
> Regarding your suggestion to carry parameters such as the 
> average rate, burst duration and peak rate, and your 
> references to RFC2697/RFC2698, I assume that this is to 
> support per MS-PW policing/queuing at S-PEs? One case where 
> per MS-PW policing will be needed is at border S-PEs where a 
> provider may not trust another provider to police individual 
> MS-PWs correctly. One case where per MS-PW queues (and 
> associated traffic counters) could be used is at border S-PEs 
> to obtain per MS-PW usage information in order to support 
> usage based inter-provider charging models. Based on these 
> inter-provider use cases, I agree that there will be a 
> requirement to carry traffic parameters in order to support 
> per MS-PW policing/queuing.
>  

I think that a minimum these parameters are necessary for admission control
at S-PEs. Note that concatenated policing must account for accumulated
variation.

> In the intra-provider case however, my view is that per MS-PW 
> policing/queuing at S-PEs will not be required (in most 
> cases). I believe a common approach will be to use per 
> MS-PW/AC policing at the edge and class based 
> queuing/policing everywhere else. At non PW switching capable 
> nodes, packets will be classified/queued based on information 
> in the tunnel LSP header (e.g. EXP field, label). At S-PEs, 
> after popping the tunnel label, packets will need to be 
> classified based on information in the MS-PW LSP header, 
> mapped to the appropriate tunnel LSP (and EXP value) and 
> queued accordingly. In this scenario, assuming each S-PE has 
> a route to reach the destination U-PE (based on reachability 
> or topology information), the MS-PW signalling protocol just 
> needs to specify how much bandwidth is required and carry 
> enough information (e.g. EXP field) to perform CAC and 
> reserve the required bandwidth for the corresponding DS-TE 
> tunnel LSP (or CT in the multi-class LSP case, 
> draft-minei-diffserv-te-multi-class-00.txt).

I agree that CAC as the principal usage in an intra-provider case.

>  
> This approach is well suited to MS-PWs that map to a single 
> class of service. If a MS-PW maps to multiple classes of 
> service then things get more complicated as the signalling 
> protocol needs to carry <bandwidth, EXP> pairs, and multiple 
> bandwidth reservations and CAC decisions must be made at each 

S-PE

> hop. In addition, in the DS-TE case, depending on the network 
> design/topology, tunnels for different CTs could potentially 
> traverse different S-PEs, making things significantly more 
> complicated.
> Rather than reserve bandwidth at each hop for some types of 
> MS-PWs, an alternative will be to set up the MS-PWs without 
> performing any CAC or reserving any bandwidth in the same way 
> that RFC2547 VPNs are set up. This approach relies on per 
> MS-PW/AC policing at the edge, and network 
> monitoring/planning to configure appropriate queue weights in 
> order to ensure that there is enough bandwidth available. 
> Obviously MS-PWs that have been setup without using CAC must 
> use different tunnel LSPs to MS-PWs setup using CAC, 
> otherwise performing CAC on those MS-PWs is a waste of time.

I am suggesting that MS-PW signaling carry object(s) that indicate the
desired quality. The set of S-PE domains traversed may use different means
for providing the requested quality. You have mentioned some possible
methods.

>  
> Regarding your suggestion to carry QoS parameters such as 
> latency, jitter, loss, my feeling is that this should be for 
> further study and is not a short term requirement (although 
> other providers may disagree ?). Firstly, to support this 
> model, standardised performance monitoring tools/MIBs would 
> be required to provide source U-PEs and S-PEs with network 
> performance information on a per tunnel LSP/class of service 
> basis. I do not believe these are available today and I am 
> not aware of any work in progress in this area? 

Some of the IPPM work could be applied here. I agree that additional work is
necessary to complete the full operational solution. The reported parameters
need not be the actual measurement, but a value that the segment can deliver
(e.g., as in PNNI).

> Secondly, in 
> the intra-provider case where class based queuing is commonly 
> used, by signalling a specific class of service for a MS-PW 
> (e.g. by specifying an EXP value) then the latency, jitter, 
> loss, etc. characteristics will be inherited from the tunnels 
> LSPs. Therefore, by mapping ACs to classes of service at the 
> edge that can meet the required (latency, jitter, loss) 
> requirements, there is no need to signal the traffic 
> characteristics using the MS-PW signalling protocol. 

This is true if the set of S-PE domains all implement the same PHB for the
EXP bits. However, this is not a general solution and may not be applicable
for all intra-provider environments, in addition to the inter-provider case
you mention below. I was proposing a more general form of solution.

>  
> This approach does not work well in the inter-provider case 
> because different providers will offer different class of 
> service options with varying traffic characteristics, and 
> therefore it may be very difficult or not possible to map 
> class of service definitions between providers. However, 
> inter-provider PW setup is a general issue and I do not think 
> the MS-PW requirements document needs to state exactly what 
> parameters must be carried in order to solve the problem as 
> these will be dependent on the solutions. For example, an 
> inter-provider solution might be developed that uses BGP for 
> signalling and routing, in which case BGP communities might 
> be used to signal QoS parameters, e.g. Well Known Community X 
> means that a MS-PW requires <200ms delay.
> 
> I agree that if the QoS requirements are too vague then we 
> need to provide further clarification, although we don't want 
> to start getting too specific otherwise we will end up trying 
> to write a protocol design specification. If consensus is 
> that the requirements document should specify exactly which 
> traffic parameters should be carried then I don't have any 
> strong objections. However, I think it will be difficult to 
> cover all current and future intra and inter provider cases 
> as QoS models vary significantly between providers and new 
> solutions will become available over time. 

We either need to get specific now, or do it later. My preference would be
to be specific in the requirements such that different solutions have the
same parameters and semantics for traffic quantity and performance quality.
Otherwise there is a good chance that different solutions will pick
different parameters, encodings and semantics.

> I would prefer to 
> define requirements along the lines of:
>  
> - The MS-PW signalling protocol must support the option to 
> carry traffic parameters that allow per MS-PS policers and 
> queues to be dynamically configured 

as well as perform admission control

> during MS-PW setup at U-PEs/S-PEs.

Suggest to the editors that they merge the traffic parameters and
(potential) policing use into 6.3.1 i.

> - The MS-PW signalling protocol must carry enough information 
> for a S-PEs to be able to select appropriate tunnel LSPs, 
> e.g. EXP field corresponding to required traffic class.

This appears to be similar to 6.3.1 i (adds EXP bit usage as example). 

> - The MS-PW signalling protocol must carry traffic parameters 
> that will support inter-provider signalling, e.g. to support 
> future PCE solutions.

I think that a more general statement is inter-AS (need not be only
inter-provider). 

>  
> Regards,
> Richard
> 
> 	-----Original Message----- 
> 	From: David McDysan [mailto:[email-masked]] 
> 	Sent: Fri 25/03/2005 09:53 
> 	To: Spencer,R,Richard,XDE73 R 
> 	Cc: [email-masked] 
> 	Subject: Proposed MS-PW "QoS" Requirements Clarifications
> 	
> 	
> 
> 	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.
> 	>       -------
> 	>