Subject: [Tsvwg] Re: Review of draft-ietf-tsvwg-diffserv-class-aggr

From: Fred Baker <[email-masked]>
Date: Fri, 12 Jan 2007 04:52:28 +0100

Thanks for your review, Dave.

Given that we update per your comments, do you feel that the document  
serves Verizon? Do you feel this is going in a direction that is  
useful to you?

On Jan 2, 2007, at 5:03 PM, Dave McDysan wrote:

> As requested, here is my review of the subject draft.
>
> Within Verizon and draft work in the MPLS FR ATM Alliance (MFA) we  
> are using
> RFC 4594 and ITU-T Y.1541 in our definitions of Diffserv, PW and  
> native MPLS
> deployments. An RFC that gave some guidance and a baseline for how  
> to map
> these various services to treatment aggregates as defined by MPLS  
> EXP bits
> would be extremely useful for internal use as well as use in  
> specifying
> network interconnections. These comments are based upon a review of  
> the
> various deployed and proposed uses of EXP bits within Verizon,  
> experience on
> negogiating interconnects with other service providers, work within  
> the MFA
> and the results of MIT Interprovider QoS workshops, as summarized  
> in the
> following:
> http://cfp.mit.edu/resources/papers/Interprovider%20QoS% 
> 20MIT_CFP_WP_9_14_06
> .pdf
>
> Suggest that in section 1, Introduction that the draft explicitly  
> state the
> assumption that all traffic is IP and marked with a particular set  
> of DSCP
> values, as described in RFC 4594.
>
> In some cases cited below bullet 5 in section 3, overview of  
> service class
> aggregation,  the traffic carried may not be IP (e.g., TDM, FR, ATM or
> Ethernet over pseudowire, VPLS). Section 2, Terminology, references  
> RFC 3270
> definitions of E-LSP and L-LSP, which include the concept of a  
> Forwarding
> Equivalency Class (FEC). I suggest that either the scope of this draft
> should be constrained to only IP and these other applications be  
> mentioned
> as out of scope, or else more text regarding handling of non-IP  
> applications
> needs to be added. For example, there could be an IP FEC and a non- 
> IP FEC
> for use with E-LSP or L-LSP from RFC 3270.
>
> Suggest that the authors add some text to section 4.1.,  Mapping  
> Service
> Classes into Four Treatment Aggregates, explaining why those chose  
> 4 instead
> of 3 or 5 treatment aggregates. From section 1, " Note that in a given
> domain, we may recommend that the supported service classes be  
> aggregated
> into forwarding treatment aggregates;   however, this does not mean  
> all
> service classes need to be supported and hence not all forwarding  
> treatment
> aggregates need to be supported." This text implies specification of a
> maximum set of treatment aggregates, and a means to map these to a  
> minimum
> set. Is the intent of this draft to specify the minimum or maximum  
> set?
>
> In Figure 1, Treatment Aggregate and Service Class Performance  
> Requirements,
> I think that broadcast video is not Real-Time. Also, in enterprise  
> VPNs, we
> have distinguished Telephony/Signaling from Mulitmedia conferencing in
> treatment aggregates in deployed networks.
>
> Section 4.1.1.  Network Control Treatment Aggregate. We view  
> network control
> as an IP-only service class, not subject to (MPLS) treatment  
> aggregation.
> Although some VPN service providers have proposed extending this  
> service
> class across an interconnect to their networks, we have convinced  
> them that
> they should map customer network control traffic (e.g., BGP, or IGP
> information for an RFC 4364 VPN) or their own network control class  
> to some
> other behavior or treatment aggregate.
>
> Suggest that the draft add some text indicating that network  
> control traffic
> is for internal use to a network. For example, Section 4.2.1 of RFC  
> 4274
> could be cited: "The Network Control precedence designation is  
> intended to
> be used within a network only.  The actual use and control of that
> designation is up to each network. [RFC791]"
>
> 4.1.2.  Real Time Treatment Aggregate. As mentioned above, current and
> planned deployments break out telephony/signaling from multimedia
> conferencing and broadcast video. If the draft is proposing that the
> real-time treatment aggregate (as defined in 1994 from RFC 1633) is  
> part of
> a minimum treatment aggregate set, then it should state this. I  
> would like
> to see mention of a larger treatment aggregate set that at least  
> splits out
> telephony/signaling from multimedia conferencing and broadcast video.
>
> 4.1.3.  Assured Elastic Treatment Aggregate. Personally, I think  
> that the
> indication of loss probability in a treatment aggregate is a good  
> idea.
> However, some deployments and plans do not use this. Also, this  
> means using
> up to an additional bit in the limited 3-bit MPLS EXP field.  
> Suggest that
> the draft state that indicating the loss probability is highly  
> desirable,
> but may not be part of the minimum set of treatment aggregates that a
> network segment may implement (see section 1).
>
> 4.1.4.  Elastic Treatment Aggregate. Personally, I think that the  
> indication
> of loss probability in a treatment aggregate is a good idea.  
> However, some
> deployments and plans do not use this. Also, this means using up to an
> additional bit in the limited 3-bit MPLS EXP field. Suggest that  
> the draft
> state that indicating the loss probability is highly desirable, but  
> may not
> be part of the minimum set of treatment aggregates that a network  
> segment
> may implement (see section 1).
>
> 5.  Using MPLS for Treatment Aggregates, first paragraph. As mentioned
> above, suggest that the authors clarify whether this is the maximum or
> minimum set of treatment aggregates as described in section 1 that are
> recommended.
>
> This section is where the most significant issues exist.
>
> 5.1.  Network Control Treatment Aggregate with E-LSP
>
> In discussions with internal users as well as discussions in the  
> MFA, there
> is not much support for using a set of MPLS EXP bits for network  
> control.
> Looking at the description for network control from RFC 4594, it  
> appears
> that most of these uses would be IP only and not be subject to MPLS
> encapsulation. The one exception we discussed is how to handle network
> control DSCP marked packets from BGP IP MPLS VPN customers. This  
> could be
> done using the proposed "110" codepoint in Figure 3, but another  
> method
> would be for the service provider to map customer network control  
> traffic to
> some other treatment aggregate (e.g., assured elastic). Suggest  
> that the
> network control treatment aggregate usage with MPLS EXP bit marking  
> be more
> clearly stated in the draft. Also, suggest that the network control
> treatment aggregate be part of the maximum treatment aggregate set.
>
> 5.2.  Real Time Treatment Aggregate with E-LSP
>
> As mentioned above, this differs from uses within Verizon, the MIT QoS
> Interprovider workshop and discussions in the MFA. The MPLS EXP bit  
> values
> of "101" are used in at least these contexts to indicate only
> telephony/signaling for EF/CS5. This is the most significant  
> difference
> between the draft and other publications and industry work. Also we  
> have
> assigned the AF4x DSCP for multimedia conferencing as MPLS EXP  
> "100," and
> also treat broadcast video as another RFC 3270 FEC.
>
> In order to resolve this comment, suggest that the draft define a  
> minimum
> subset of the "real-time" treatment aggregate and mention that some  
> network
> segments (see section 1) may define a larger set along the lines of  
> what I
> mention above.
>
> Sections 5.3 (5.4) Assured Elastic (Elastic) Treatment Aggregate  
> with E-LSP
>
> These MPLS EXP code points (without the loss probability bit  
> encoding) are
> what is used in several VPN and public IP networks.
>
> Section 5 - Additional comments
>
> If the scope decision of this document is to expand to non-IP  
> applications,
> then additional text on handling Pseudowires with client services  
> having
> their own QoS definitions, VPLS and other potential uses of MPLS  
> would need
> to be added. My recommendation would be to keep this document  
> focused on the
> IP applications, and if anyone is interested then another document  
> that
> covered non-IP applications could be drafted.
>
> 6.  Treatment Aggregates and Inter-Provider Relationships
>
> Suggest addition of a reference to the MIT QoS Interprovider white  
> paper
> mentioned above. After much discussion, the service providers  
> involved in
> this effort were only able to agree on a minimum set of two treatment
> aggregates.
>
> Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541.  
> Appendix
> VI defines a minimum set of three QoS classes and a mapping to  
> (sets of)
> IETF DSCP values as follows:
>
> Y.1221            Associated    Y.1541
> Transfer          Diffserv      QoS
> Capability        PHBs          Class(es)
> ------------      ----------    --------
> Best Effort       Default       5
>
> Delay-Sensitive   AF            2,3,4
> Statistical BW
>
> Dedicated         EF            0,1
> Bandwidth
>
> (If you don't have ITU access, you can get up to three free ITU-T  
> documents
> per Email address by going to www.itu.int and going to the purchase  
> page and
> entering your email address.)
>
> Many international providers look to the ITU-T for guidance, and  
> that would
> be the focus on many of our network provider interconnection uses of
> treatment aggregates and MPLS EXP bit markings. Therefore, at least  
> some
> mention of a similar minimum subset of aggregations proposed by the  
> ITU-T in
> this document would be valuable. Finally, I note that if network  
> control is
> removed from the minimum subset in this draft, then the above set  
> from ITU-T
> Y.1541 Appendix VI is equivalent in terms of number of treatment  
> aggregates
> and a high-level mapping of service capabilities.
>
> Regards,
>
> Dave
>
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[email-masked]]
>> Sent: Thursday, December 07, 2006 10:32 AM
>> To: tsvwg
>> Subject: [Tsvwg] Need for volunteers for reviewing
>> draft-ietf-tsvwg-diffserv-class-aggr
>>
>> Hi,
>>
>> To make progress we need some reviewers to read and comment
>> on "Aggregation of DiffServ Service Classes":
>>
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class- 
> aggr-01.
> txt
>>
>> We chairs don't think we can proceed with this draft until we
>> seen some confirming reviews from the WG participants. So
>> please volunteer.
>>
>> If you are willing to do this review please indicate so to us chairs.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> IETF Transport Area Director & TSVWG Chair
>> --------------------------------------------------------------------- 
>> -
>> Multimedia Technologies, Ericsson Research EAB/TVA/A
>> --------------------------------------------------------------------- 
>> -
>> Ericsson AB                | Phone +46 8 4048287
>> Torshamsgatan 23           | Fax   +46 8 7575550
>> S-164 80 Stockholm, Sweden | mailto: [email-masked]
>> --------------------------------------------------------------------- 
>> -
>>
>>
>>

---

From: Dave McDysan <[email-masked]>
Date: Fri, 12 Jan 2007 08:41:38 -0500

Fred,

I would like to see the document be of broader use than a single company.
This is why I referenced the MFA work, which references this draft. It uses
the '101' codepoint for real-time and does not state that support for the
network control treatment aggregate is mandatory.

With the changes that I suggested, I think this document is going in a
direction that is useful to the MFA, of which several service providers
(including Verizon) believe this work is important.

As mentioned in the comments, I am proposing that this document be focused
on how to best support aggregation of treatements for IP and that the issues
of how to support pseudowires, VPLS and pt-mpt be handled in a separate
document so that something useful for IP is delivered first.

Dave 

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Thursday, January 11, 2007 10:52 PM
> To: Dave McDysan
> Cc: 'Magnus Westerlund'; 'tsvwg'; 'Kwok-Ho Chan'; [email-masked]
> Subject: Re: Review of draft-ietf-tsvwg-diffserv-class-aggr
> 
> Given that we update per your comments, do you feel that the 
> document serves Verizon? Do you feel this is going in a 
> direction that is useful to you?
> 
> > Within Verizon and draft work in the MPLS FR ATM Alliance 
> (MFA) we are 
> > using RFC 4594 and ITU-T Y.1541 in our definitions of 
> Diffserv, PW and 
> > native MPLS deployments. An RFC that gave some guidance and 
> a baseline 
> > for how to map these various services to treatment aggregates as 
> > defined by MPLS EXP bits would be extremely useful for 
> internal use as 
> > well as use in specifying network interconnections. These 
> comments are 
> > based upon a review of the various deployed and proposed 
> uses of EXP 
> > bits within Verizon, experience on negogiating interconnects with 
> > other service providers, work within the MFA and the results of MIT 
> > Interprovider QoS workshops, as summarized in the
> > following:
> > state the assumption that all traffic is IP and marked with a 
> > particular set of DSCP values, as described in RFC 4594.
> >
> > In some cases cited below bullet 5 in section 3, overview 
> of service 
> > class aggregation,  the traffic carried may not be IP 
> (e.g., TDM, FR, 
> > ATM or Ethernet over pseudowire, VPLS). Section 2, Terminology, 
> > references RFC 3270 definitions of E-LSP and L-LSP, which 
> include the 
> > concept of a Forwarding Equivalency Class (FEC). I suggest 
> that either 
> > the scope of this draft should be constrained to only IP and these 
> > other applications be mentioned as out of scope, or else more text 
> > regarding handling of non-IP applications needs to be added. For 
> > example, there could be an IP FEC and a non- IP FEC for use 
> with E-LSP 
> > or L-LSP from RFC 3270.
> >
> > Service Classes into Four Treatment Aggregates, explaining 
> why those 
> > chose
> > 4 instead
> > treatment aggregates need to be supported." This text implies 
> > specification of a maximum set of treatment aggregates, and 
> a means to 
> > map these to a minimum set. Is the intent of this draft to 
> specify the 
> > minimum or maximum set?
> >
> > Requirements, I think that broadcast video is not 
> Real-Time. Also, in 
> > enterprise VPNs, we have distinguished Telephony/Signaling from 
> > Mulitmedia conferencing in treatment aggregates in deployed 
> networks.
> >
> > Section 4.1.1.  Network Control Treatment Aggregate. We 
> view network 
> > control as an IP-only service class, not subject to (MPLS) 
> treatment 
> > aggregation.
> > service class across an interconnect to their networks, we have 
> > convinced them that they should map customer network 
> control traffic 
> > (e.g., BGP, or IGP information for an RFC 4364 VPN) or their own 
> > network control class to some other behavior or treatment aggregate.
> >
> > Suggest that the draft add some text indicating that 
> network control 
> > traffic is for internal use to a network. For example, 
> Section 4.2.1 
> > of RFC
> > 4274
> > intended to be used within a network only.  The actual use 
> and control 
> > of that designation is up to each network. [RFC791]"
> >
> > part of a minimum treatment aggregate set, then it should 
> state this. 
> > I would like to see mention of a larger treatment aggregate 
> set that 
> > at least splits out telephony/signaling from multimedia 
> conferencing 
> > and broadcast video.
> >
> > 4.1.3.  Assured Elastic Treatment Aggregate. Personally, I 
> think that 
> > the indication of loss probability in a treatment aggregate 
> is a good 
> > idea.
> > However, some deployments and plans do not use this. Also, 
> this means 
> > using up to an additional bit in the limited 3-bit MPLS EXP field.
> > Suggest that
> > desirable, but may not be part of the minimum set of treatment 
> > aggregates that a network segment may implement (see section 1).
> >
> > additional bit in the limited 3-bit MPLS EXP field. Suggest 
> that the 
> > draft state that indicating the loss probability is highly 
> desirable, 
> > In discussions with internal users as well as discussions 
> in the MFA, 
> > there is not much support for using a set of MPLS EXP bits 
> for network 
> > control.
> > appears that most of these uses would be IP only and not be 
> subject to 
> > MPLS encapsulation. The one exception we discussed is how to handle 
> > network control DSCP marked packets from BGP IP MPLS VPN customers. 
> > This could be done using the proposed "110" codepoint in 
> Figure 3, but 
> > another method would be for the service provider to map customer 
> > network control traffic to some other treatment aggregate (e.g., 
> > assured elastic). Suggest that the network control 
> treatment aggregate 
> > usage with MPLS EXP bit marking be more clearly stated in 
> the draft. 
> > Also, suggest that the network control treatment aggregate 
> be part of 
> > the maximum treatment aggregate set.
> >
> > values of "101" are used in at least these contexts to 
> indicate only 
> > difference between the draft and other publications and 
> industry work. 
> > Also we have assigned the AF4x DSCP for multimedia conferencing as 
> > MPLS EXP "100," and also treat broadcast video as another RFC 3270 
> > FEC.
> >
> > minimum subset of the "real-time" treatment aggregate and 
> mention that 
> > some network segments (see section 1) may define a larger set along 
> > the lines of what I mention above.
> >
> > Sections 5.3 (5.4) Assured Elastic (Elastic) Treatment 
> Aggregate with 
> > E-LSP
> >
> > applications, then additional text on handling Pseudowires 
> with client 
> > services having their own QoS definitions, VPLS and other potential 
> > uses of MPLS would need to be added. My recommendation would be to 
> > keep this document focused on the IP applications, and if anyone is 
> > interested then another document that covered non-IP applications 
> > could be drafted.
> >
> > paper mentioned above. After much discussion, the service providers 
> > involved in this effort were only able to agree on a minimum set of 
> > two treatment aggregates.
> >
> > VI defines a minimum set of three QoS classes and a mapping 
> to (sets 
> > of) IETF DSCP values as follows:
> >
> > Y.1221            Associated    Y.1541
> > Transfer          Diffserv      QoS
> > documents per Email address by going to www.itu.int and 
> going to the 
> > purchase page and entering your email address.)
> >
> > Many international providers look to the ITU-T for 
> guidance, and that 
> > would be the focus on many of our network provider interconnection 
> > uses of treatment aggregates and MPLS EXP bit markings. 
> Therefore, at 
> > least some mention of a similar minimum subset of aggregations 
> > proposed by the ITU-T in this document would be valuable. 
> Finally, I 
> > note that if network control is removed from the minimum subset in 
> > this draft, then the above set from ITU-T
> > aggregates and a high-level mapping of service capabilities.
> >
> > Regards,
> >
> > Dave
> >
> >> To make progress we need some reviewers to read and comment on 
> >> "Aggregation of DiffServ Service Classes":
> >>
> >> We chairs don't think we can proceed with this draft until we seen 
> >> some confirming reviews from the WG participants. So please 
> >> volunteer.
> >>