Subject: [tsvwg] Diffserv discussion yesterday

From: <[email-masked]>
Date: Thu, 2 Aug 2012 12:07:36 -0400

There was a lengthy discussion in yesterday's tsvwg meeting around James's
diffserv problem statement draft and the liaison from ITU-T SG12/Q17 on
QoS classes and markings for interconnection.

Here's the summary of the interesting points that I captured from the4 discussion:

- We may be looking at a tunnel structure where the RFC 4594 classes and markings
        are used in the inner IP header (can be viewed as enterprise-oriented),
        but a much smaller number of classes/markings (e.g., see RFC 5127 and
        ITU-T liaison) are used in the outer MPLS header's TC bits (can be
        viewed as carrier- and inter-carrier-oriented).  That smaller number of
        aggregates could also apply to the Ethernet priority field.
- The ITU-T liaison can be read as also asking if the treatment aggregates in
        RFC 5127 are the right ones.  This may be much more important than
        whether the right RFC 4594 classes are in each RFC 5127 traffic aggregate.
- In addition, RFC 5127 needs some more detailed work, e.g., as VOICE-ADMIT
        isn't included, but figuring out whether RFC 5127 has the right treatment
        aggregates is more important.
- The response to the ITU-T liaison is not due until next March so there is time
        to consider the issues.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: James Polk <[email-masked]>
Date: Thu, 02 Aug 2012 13:57:58 -0500

David

(as an individual/author)

I agree with your first two bullets as stated.

I also agree with bullet #3 that RFC 5127 needs to be updated, and 
agree SG12's liaison statement presentation (at least) gave the 
impression that these outer markings are inconsistent with between 
the 2 efforts (RFC 5127 and SG12's "question" on the topic).

I think it was slide 5 of the SG12 Liaison preso that particularly 
caught my eye as to just how inconsistent the two are, and yet helped 
greatly determine that "the inner packet markings aren't to be 
overwritten or changed through SG12's effort". This was news to me, 
and I'm glad to have heard that finally. Maybe I was slow. It appears 
SG12 has a lot of different voice and video markings, yet RFC 5127 
has only 1 treatment aggregate for "realtime". If there are to be 
synergies between the two documents, work on an agreement isn't 
really close - but might not be hard to achieve. I'm not sure, 
because discussion up until yesterday's presentations appears to have 
been talking past each other - perhaps - with neither side fully 
realizing just how far away we were talking. I feel partly 
responsible for that, and want to work towards fixing it immediately.

Your bullet 4 is also good to know (from what Eliot said in the 
room), but we shouldn't wait until February to start this (as we 
authors often do with ID deadlines -- i.e., don't start the work 
until the weekend before the deadline)). This part I'm saying as much 
with my WG chair hat on as an individual.

James

---

From: <[email-masked]>
Date: Thu, 2 Aug 2012 16:55:55 -0400

James,

I think we're in agreement, and I would *definitely* like to see comments
and opinions from others ... please do comment, as the implications of
what we do here may be significant.

> with my WG chair hat on as an individual.

Specifically, I think we need a clear understanding of what (if anything)
we (the IETF transport area) intend to do to/with RFC 5127 before we can
craft an effective liaison response.

Thanks,
--David

> -----Original Message-----
> From: James Polk [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 2:58 PM
> To: Black, David; [email-masked]
> Subject: Re: [tsvwg] Diffserv discussion yesterday
> 
> David
> 
> >         are used in the inner IP header (can be viewed as  enterprise- oriented),

---

From: James Polk <[email-masked]>
Date: Thu, 02 Aug 2012 16:38:13 -0500

David

Indeed, and we have a problem with timing on that one - which I'm 
sure you've figured out already. I know I don't own anything here, 
but I as I've said before I was planning write an update to RFC 5127, 
focusing on aligning it to whatever was agreed to for the update to 
RFC 4594 wrt any new service classes, and the agreed to names of 
each. The current update to RFC 4594 has several new service classes, 
and several existing ones renamed. This was going to me my focus of 
the RFC 5127 update, as I don't personally believe that it would 
receive the scale of rewrite that I've given to the update to RFC 
4594. That said, with respect to the existing  4 treatment aggregates 
within RFC 5127, I was going to open up a fairly serious debate on 
whether there ought to be a 5th aggregate specifically for 
capacity-admitted service classes (which are already in the RFC 4594 
update proposal). I don't know if this 5th aggregate is needed, but I 
think it might be.

Getting all that hashed out before we craft the response to SG12's 
liaison statement will be challenging (at best), in my view, 
especially with the seen differences between SG12's liaison 
presentation table on slide 5 compared to the existing treatment 
aggregates in RFC 5127 (which I put into the DiffServ problem 
statement draft and presentation).

James

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Aug 2012 16:20:02 -0700

James,

> statement draft and presentation).

I would suggest that you answer with what the working group has
concluded around the time of the deadline, if you need to take that
long.  No need to rush, and you can always indicate problems and open
questions that are raised by the work.

Eliot

---

From: <[email-masked]>
Date: Thu, 2 Aug 2012 19:47:26 -0400

James,

I suggest engagement on the RFC 5127 aggregate discussion without
waiting for a determination of which classes will and/or will not
be added to RFC 4594.

IMHO, it's not necessary to publish a 5127bis RFC based solely on
the conclusion of the aggregate discussion.  OTOH, once that
discussion is concluded, I would hope that assignment of new classes
in 4594bis to the applicable aggregates would be reasonably
straightforward.

Thanks,
--David

> Sent: Thursday, August 02, 2012 5:38 PM
> To: Black, David; [email-masked]; [email-masked]
> Cc: Eliot Lear
> Subject: RE: [tsvwg] Diffserv discussion yesterday
>

---

From: James Polk <[email-masked]>
Date: Thu, 02 Aug 2012 20:39:42 -0500

>questions that are raised by the work.

agreed

James

---

From: James Polk <[email-masked]>
Date: Thu, 02 Aug 2012 20:47:51 -0500

David

Yes, I agree this liaison request is accelerating the work on 5127bis 
due to the disparity in treatment aggregates vs. what SG12 wants in 
their recommendation. I fully expect both the 4594bis (as you call 
it) and 5127bis documents to align as soon as is possible on both the 
service classes including names) and number and names of treatment aggregates.

I'll open a dialog with Al and Ruediger about exactly what they are 
expecting or wanting the treatment aggregates to change to, as well 
as what goes in each. I want to understand that a lot better. In that 
understanding, perhaps we can reach common ground.

James