Subject: Re: [tsvwg] David Black's comments on draft-geib-tsvwg-diffserv-intercon-

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Mar 2013 08:40:16 +0000

On 28/02/2013 23:09, Black, David wrote:
...
> The introduction should explain more about copying of the "IP Precedence Bits"
> to the MPLS TC or Ethernet P-Bits - the crucial thing that needs to be stated
> is that the bits involved are the first 3 bits in the DSCP, and the values
> for the recommended DSCPs for AF and EF were chosen in part based on this
> consideration, so that EF has a higher priority than AF (and most other
> traffic) when this is done.  This is described in Section 5, but should
> also be explained in the introduction. 

It should also, IMHO, be made clear that this is a bit of a hack,
originally intended for the benefit of legacy IPv4 routers that were
not diffserv-aware. The correct technique is a mapping table from
DSCP to 3-bit value, not a dumb mask.

   Brian

---

From: <[email-masked]>
Date: Fri, 1 Mar 2013 13:10:33 +0100

Hello David,

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

[DB] David Black
[RG] Rüdiger Geib

Regards,

Rüdiger

########################

[DB] These comments are as an individual - <WG co-chair hat off>

[DB] In general, this is a valuable contribution, including the specific
     proposal of the 4 diffserv interconnect classes.  It may be a good
     idea to add a mapping from the current RFC 4594 classes into
     these classes as a complement to the current PHB-oriented material.

[RG] I agree. We should clarify the role of RFC5127.

[DB] Abstract and Introduction: A possible tsvwg direction forward is to
     revise RFC 5127 to focus on network internals and produce a separate
     RFC for interconnection of network edges - that separation is
     consistent with the discussion in Section 3 of this draft about
     mapping between internal and interconnection schemes.

     That distinction between schemes is crucial, IMHO - it's in the
     second paragraph of this draft's introduction, but could use some
     more emphasis. OTOH, I'd remove the text that focuses this draft
     on revising RFC 5127, as that may not be the most effective path
     forward, although it'd probably be ok to retain some of the language
     in the introduction about concepts in this draft being relevant to
     a revision of RFC 5127.

[RG] Yes, we should clarify how to make progress on DiffServ-Intercon and
RFC 5127. I think, both are linked. If both progress apart, some text
should explain why they are kept apart. I'd also expect that
DiffServ-Intercon would make faster progress if kept separate from RFC5127.

[DB] The introduction should explain more about copying of the "IP Precedence
     Bits" to the MPLS TC or Ethernet P-Bits - the crucial thing that
     needs to be stated is that the bits involved are the first 3 bits
     in the DSCP, and the values for the recommended DSCPs for AF and EF
     were chosen in part based on this consideration, so that EF has a
     higher priority than AF (and most other traffic) when this is done.
     This is described in Section 5, but should also be explained in the
     introduction.

[RG] You are correct, the first three bits of the DSCP are important, not
the IP Precedence class concept. Any other term is allright with me. I'll
change that for version -03.

[DB] The last paragraph on p.3 indicates that internal PHBs and codepoints
     may be added later - I don't think that would be a good idea.  Rather,
     it'd be better (IMHO) to focus this draft on the interconnect problem
     to keep it cleanly separated from the RFC 4594 update discussion that
     also affects RFC 5127. That paragraph could also use some minor
     rephrasing to avoid any implication that this draft has priority on
     use of MPLS TC space - talking about other uses as peer users of that
     space would be better than the current "leave some MPLS TC codespace"
     language.

[RG] The internal classes don't need to be part of DiffServ-Intercon. Some
guidance on mapping of these internal classes may be given and I wouldn't
exclude using CS6 for EBGP. Some routers may not be able to use anything
else but CS6 for internal traffic. But that's rather an infomative addition
than my core interest.
This draft should not say that more MPLS TCs are required than those
four indicated. There are no other Intercon-classes I think about. I'll
try to change text (but I'm no native spreaker).

{DB] It's recently been discovered that draft-ietf-idr-sla-exchange-00.txt
     is related to this work, so that draft should be mentioned.  The
     idr-sla-exchange draft is rather descriptive, in contrast to this
     diffserv interconnect draft being prescriptive.

[RG] I guess a reference is possible, but I will have to check how far
that goes. I have to discuss that internally, as one of the IDR
old hands is from the company I work for.

[DB] The middle bullet in the list at the end of section 3 isn't
     quite right. There are only 8 codepoints available for DSCP encoding
     in MPLS and Ethernet, but some PHBs (e.g., AF) can consume more than
     one codepoint.  The last bullet at the end of section 3 is unclear
     on whether this is about DSCPs, MPLS (and Ethernet) codepoints,
     or both.

[RG] Let's disuss that: An offered class AF3 consumes one MPLS TC
(e.g. 3). However PHBs AF31 and AF32 if offered could consume 2 MPLS
TCs, say 3 and 2. And if ECN is to be supported for a class AF4, than
an additional MPLS TC would be required: in the example AF4 corresponds
to MPLS TC 4 not-CM and MPLS TC 7 may indicate AF4 CM. 8 is the sum of
DSCP and ECN.
The last section refers to both, DSCP and MPLS TC, I will clarify.

[DB] The first 3 paragraphs of section 4 feel like they belong in a
     related work section, possibly an appendix, which would also be
     a good place for a longer discussion of Y.1566, which is the basis
     for a lot of this material.

[RG] Can be moved. Maintaining the information is important, but not
making it part of the proposed solution. I'd like to add interworking
guidance.

[DB] I'm not sure I understand the point of Section 6, and would
     suggest removing it.

[RG] Let me think about that. I've used wrong terminology (forwarding
and AQM is meant where I speak of conditioning - sorry, very sloppy
of me). I want to get rid of discussions why a class "Streaming Audio"
is mapped into a class "Multimedia" in my professional life. I'd rather
like to have a discussion  about class properties and SLA expectations.
As "avoid giving application names to DiffServ classes" is standard
guidance given by networking engineers, I'm not the only one suffering.
That's motivates this "QoS standardisation pitfalls" section.
It may be made informational and I try to reword. But it should be kept.

[DB] I would also combine sections 5 and 7 into a single section.

{RG] Will do so in version -03.

---

From: <[email-masked]>
Date: Wed, 6 Mar 2013 13:41:43 +0100

Brian,

while that may have been the original intention, it took years until router vendors
supported a mapping table from DSCP to 3-bit value. But that's not all. MPLS networks
may be operated with Pen-ultimate Hop Popping, meaning that public IP traffic passes
the last MPLS hop without a label. In that case full DSCP based classification is
not desireable, the forwarding should be class based (i.e. 3-bit based).

Regards,

Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Friday, March 01, 2013 9:40 AM
To: Black, David
Cc: [email-masked]
Subject: Re: [tsvwg] David Black's comments on draft-geib-tsvwg-diffserv-intercon-

   Brian

---

From: "Black, David" <[email-masked]>
Date: Wed, 6 Mar 2013 10:08:03 -0500

Ok, so Brian's "bit of a hack" may not have been the ideal words, and I've done far
worse in email ;-), but he's absolutely correct that full mapping of individual DSCP
values is the "right answer" for this.  Nonetheless, as Ruediger points out, between
gear w/o diffserv support and MPLS PHP, there are "running code" benefits in practice
from assigning DSCPs in a fashion that keeps the original IPv4 use of the first 3
bits of the DSCP field in mind.

That sort of explanation would probably be useful in the draft.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, March 06, 2013 7:42 AM
> To: [email-masked]
> Cc: [email-masked]