Subject: [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt

From: <[email-masked]>
Date: Mon, 25 Feb 2013 13:41:30 +0100

Hello,

below you'll find the links to a revised version of the DiffServ
intreconnection scheme. I forgot some references in version -01,
so I added a version -02 before cutoff. To simplify comparing
it with -00, here's a diff -00 vs. -02:

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-geib-tsvwg-diffserv-intercon-00.txt&url2=http://tools.ietf.org/id/draft-geib-tsvwg-diffserv-intercon-02.txt

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2013 12:20 PM
To: Geib, Rüdiger
Subject: New Version Notification for draft-geib-tsvwg-diffserv-intercon-02.txt

A new version of I-D, draft-geib-tsvwg-diffserv-intercon-02.txt
has been successfully submitted by Ruediger Geib and posted to the
IETF repository.

Filename:        draft-geib-tsvwg-diffserv-intercon
Revision:        02
Title:           DiffServ interconnection classes and practice
Creation date:   2013-02-25
Group:           Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffserv-intercon-02.txt
Status:          http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon
Htmlized:        http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-intercon-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-geib-tsvwg-diffserv-intercon-02

Abstract:
   This document proposes a limited set of interconnection QoS PHBs and
   PHB groups.  It further introduces some DiffServ deployment aspects.
   The proposals made here should be integrated into a revised version
   of RFC5127.

---

From: <[email-masked]>
Date: Mon, 25 Feb 2013 15:07:12 +0100

Dear Reuediger,

Thank you for updating the draft. Below some additional comments and text proposal: 

* The document mentions SLA without citing a reference. FWIW, you can cite http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profile-02. That document defines various performance guarantees clauses to be included in a connectivity agreement (can be used between two network providers). 

* You may add the following text to the introduction:

   The current practices in operational network is to reset DSCP to 0
   in interconnection points.  An ASBR does not trust the marking set by
   an external adjacent ASBR.  This practice is likely to evolve if
   interconnection agreements are reviewed to include QoS performance
   guarantees.  Those agreements may include in particular the marking
   policy to be enforced in the interconnection link.

* I fully agree having a well defined set of classes will ease QoS interconnection practices (e.g., how to bound my classes to those of an adjacent domain). Nevertheless, having standard codepoints assigned to those QoS classes may be of less interest if we assume these values are agreed between adjacent provided and are captured in an interconnection agreement. The text should motivate further such need. You may add the following for instance:

   Having a limited set of codepoints for QoS interconnect are likely to
   accelerate network provisioning by providing generic policies to be
   enforced at the interconnection nodes.  The use of standard code points
   ease automation of network interconnection agreement and settlement procedures.
 
* You may also add the following:

   Network providers may agree to use other codepoints than those
   defined in this document.  

   This document does not require network
   providers to expose their internal QoS configuration (e.g., number QoS
   classes, internal DSCP codepoints, classification policies, etc.).

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de [email-masked]
>Envoyé : lundi 25 février 2013 13:42
>À : [email-masked]
>Objet : [tsvwg] New version notification 
>draft-geib-tsvwg-diffserv-intercon-02.txt
>
>Hello,
>
>http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/dra
>ft-geib-tsvwg-diffserv-intercon-00.txt&url2=http://tools.ietf.o
>rg/id/draft-geib-tsvwg-diffserv-intercon-02.txt
>
>Regards,
>
>Ruediger
>
>Subject: New Version Notification for 
>draft-geib-tsvwg-diffserv-intercon-02.txt
>
>
>URL:             
>http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffserv-i
>ntercon-02.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon
>Htmlized:        
>http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-intercon-02
>Diff:            
>http://www.ietf.org/rfcdiff?url2=draft-geib-tsvwg-diffserv-intercon-02
>
>Abstract:

---

From: <[email-masked]>
Date: Thu, 28 Feb 2013 13:13:16 +0000

Hi, 

First of all, I appreciate this work, especially as it clearly points out that only a limited number of classes is deployed in the core networks in practice (similarly to RFC5127).

I reviewed the latest version of this draft, and I spent some time also having a look to Y.1566.
Please find below some of my comments.

- Page 6, you mention 4 classes (Class Priority, Bulk inelastic, Assured, Default) with a reference to Y.1566. However, in Y.1566, the 4 classes corresponding to "Ordinary Packet Service QoS Classes" are not the same (e.g. Critical / network management class is missing in your IETF draft), and it seems that you actually mixed classes mentioned as "auxiliary Packet Service QoS Classes" in Y.1566 (e.g. Bulk inelastic belongs to this second set in Y.1566). Is there a reason for this? Should the two documents be aligned?

- Page 7, you say that: "At interconnection points, the following PHBs should be accepted between interconnected parties:" Does it imply that it is expected that all the operators implement exactly these PHBs in their network in each node? It seems quite difficult for me to mandate that all the networks behave the same way, since various network operators have in general different configurations/policies. I thought that the original proposal was simply to define a set of codepoints for interconnection points, but leave the actual network behavior as operator-specific (which is quite reasonable). Did I misunderstand something?

- You mention the term "conditioning" at several places in your draft; could you define precisely what is meant by this? For instance, is it referring to the properties of one particular class of service? Else?

- About MPLS TC or Ethernet P-Bits and IP precedence, I'll tend to think that referencing the old IP precedence mechanism may not be the most effective way to explain what is suggested (and done in practice) - you might perhaps simply mention that the first 3 bits of the DSCP are used, it might be clearer. I would personally suggest not talking about IP precedence at all.

Finally, I wonder if a possible revision of RFC5127 might include most of the aspects discussed in this draft. Indeed, the classes (treatment aggregates) described in RFC5127 should ideally be aligned with this draft. Also, current RFC5127 contains a section 5 called "Treatment Aggregates and Inter-Provider Relationships". This could potentially be a place where to put some of the considerations on interconnection points.

I won't be in Orlando, but I'll try to follow remotely these discussions.

Thanks.

BR,

Sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 25 février 2013 13:42
À : [email-masked]
Objet : [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt

Hello,

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2013 12:20 PM
To: Geib, Rüdiger
Subject: New Version Notification for draft-geib-tsvwg-diffserv-intercon-02.txt

Abstract:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 28 Feb 2013 14:31:24 +0100

Dear Med

thanks for your comments. I mark your comments and my replies below as follows:

[MB] Mohamed Boucadair
[RG] Ruediger Geib

Regards,

Ruediger

--------

    [MB] The document mentions SLA without citing a reference.
      FWIW, you can cite http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profile-02.
      That document defines various performance guarantees clauses
      to be included in a connectivity agreement (can be used
      between two network providers).

[RG] That would be an example of an SLA. Yes, such a reference could
be added in -03.

    [MB] You may add the following text to the introduction:

[RG] Such a statement could be added. Apart from the trust issue, there are
others: a carrier doesn't know the class corresponding to a received DSCP.
Further, a carrier will protect the own QoS classes from interference of
uncontrolled external traffic,

    [MB] I fully agree having a well defined set of classes will ease QoS
       interconnection practices (e.g., how to bound my classes to those
       of an adjacent domain). Nevertheless, having standard codepoints
       assigned to those QoS classes may be of less interest if we
       assume these values are agreed between adjacent provided and are
       captured in an interconnection agreement. The text should motivate
       further such need. You may add the following for instance:

       Having a limited set of codepoints for QoS interconnect are likely to
       accelerate network provisioning by providing generic policies to be
       enforced at the interconnection nodes.  The use of standard code points
       ease automation of network interconnection agreement and settlement
       procedures.

[RG] Thanks, understood and I agree. I will add your text or similar one to the
arguments already given in version -03.

    [MB] You may also add the following:

[RG] Thanks, I had the former in mind already. It's one reason why there should
be some codepoint reserve left. Will be added too in -03.

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 28 Feb 2013 16:46:48 +0100

Hello Sebastien,

thanks for your comments. Your statements and my replies are marked as follows below:

[SJ] Sebastien Jobert
[RG] Rüdiger Geib

Regards,

Rüdiger

----------

     [SJ] Page 6, you mention 4 classes (Class Priority, Bulk inelastic, Assured, Default)
     with a reference to Y.1566. However, in Y.1566, the 4 classes corresponding to
     "Ordinary Packet Service QoS Classes" are not the same (e.g. Critical / network management
     class is missing in your IETF draft), and it seems that you actually mixed classes
     mentioned as "auxiliary Packet Service QoS Classes" in Y.1566 (e.g. Bulk inelastic
     belongs to this second set in Y.1566). Is there a reason for this? Should the two
     documents be aligned?

[RG] DiffServ-Intercon and Y.1566 should be aligned (and I'd add GSMA IR.34 and MEF 23.1).
ITU reached agreement on those classes all carriers support ("ordinary") and some which
see some support ("auxiliary"). ITU worked with full consensus here, not with rough
consensus. That's why I included class Bulk Inealstic in the IETF work more prominently
(but look for section 6 of Y.1566, it is proposed there too). ITU class critcal (network management)
is mentioned in the DiffServ-Intercon introduction:...An example for an internal PHB may be CS6...
I'm happy to expand on that, given there's support.

     [SJ] Page 7, you say that: "At interconnection points, the following PHBs should be
     accepted between interconnected parties:" Does it imply that it is expected that all
     the operators implement exactly these PHBs in their network in each node? It seems
     quite difficult for me to mandate that all the networks behave the same way, since
     various network operators have in general different configurations/policies. I thought
     that the original proposal was simply to define a set of codepoints for interconnection
     points, but leave the actual network behavior as operator-specific (which is quite
     reasonable). Did I misunderstand something?

[RG] Good point, I may be unclear here. I'd expect the classes to be supported. Class
definitions should stay qualitative. Class properties should be standardised. The PHBs
should be maintained in the sense that if received with different codepoints at
interconnection, they should leave with different codepoints on interconnection. So
treating different PHBs of one class only as one class is allright.
The minimum expectation then is support of a class a specified, if the Intercon class
and codepoint scheme is used. I don't think there should be an obligation to support
all four classes that's a SHOULD at best. I guess the draft needs to say that.

     [SJ] You mention the term "conditioning" at several places in your draft; could
     you define precisely what is meant by this? For instance, is it referring to
     the properties of one particular class of service? Else?

[RG] Good point and I obviously need to expand terminology. By conditioning I meant
scheduling & Active Queue Management (if any). And here "conditioning" doesn't apply
 - that has been a late change and an ill formulated one. Sorry for causing
confusion.
In fact, what's needed is something "QoS forwarding". I'm open for better suggestions.

     [SJ] About MPLS TC or Ethernet P-Bits and IP precedence, I'll tend to think that
     referencing the old IP precedence mechanism may not be the most effective way to
     explain what is suggested (and done in practice) - you might perhaps simply
     mention that the first 3 bits of the DSCP are used, it might be clearer. I
     would personally suggest not talking about IP precedence at all.

[RG] Good idea. If the WG reaches conensus that the first 3 bits of the DSCPs are used
to the purpose I specify (and in fact: specification follows implementation here)
I'm happy to rewrite the draft without refering to IP-precedence. I'll add that to the
presentation.

     [SJ] Finally, I wonder if a possible revision of RFC5127 might include most of
     the aspects discussed in this draft. Indeed, the classes (treatment aggregates)
     described in RFC5127 should ideally be aligned with this draft. Also, current
     RFC5127 contains a section 5 called "Treatment Aggregates and Inter-Provider
     Relationships". This could potentially be a place where to put some of the
     considerations on interconnection points.

[RG] Basically you are right. But to me RFC5127 requires a rewrite also without the
contents of DiffServ-Intercon. I'd be very unhappy if consensus was reached on
DiffServ-Intercon but the all is delayed because there's no consensus
on a RFC5127 rewrite. I'm open for a discussion however.