Subject: draft-ietf-tsvwg-intserv-multiple-tspec-00 submitted

From: "James M. Polk" <[email-masked]>
Date: Sun, 03 Jul 2011 19:17:20 -0500

TSVWG

(with my individual hat on)

We'd like to draw your attention to the newest WG item within TSVWG.

The authors made only a couple of individual modifications from the 
individual version that was approved as a WG item:

- clarified how this extension also extends RFC 4495 (RSVP Bandwidth 
Reduction), and
- added some text to the security considerations section

The top item has to do with good network hygiene - correcting as soon 
as possible when too much BW was reserved (that is no longer needed) 
within part of a reservation setup. The latter item was directly from 
a review comment.

Both of these we thought we low hanging fruit, so we put them in this 
version. Any further changes needs WG approval in our opinion.

Comments are encouraged and/or requested.

James & Subha

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories. This draft is a work item of the Transport Area Working 
>Group Working Group of the IETF.
>
>         Title           : Integrated Services (IntServ) Extension 
> to Allow Signaling of Multiple Traffic Specifications and Multiple 
> Flow Specifications in RSVPv1
>         Author(s)       : James Polk
>                           Subha Dhesikan
>         Filename        : draft-ietf-tsvwg-intserv-multiple-tspec-00.txt
>         Pages           : 26
>         Date            : 2011-07-03
>
>    This document defines extensions to Integrated Services (IntServ)
>    allowing  multiple traffic specifications and multiple flow
>    specifications to be conveyed in the same Resource Reservation
>    Protocol (RSVPv1) reservation message exchange. This ability helps
>    optimize an agreeable bandwidth through a network between endpoints
>    in a single round trip.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>This Internet-Draft can be retrieved at:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Jul 2011 14:27:21 -0400

James,
	Since you ask...

I thought this would be a good time to revive our discussion from March.
 As a reminder, here is the salient part of the discussion:

On 3/18/2011 5:04 PM, James M. Polk wrote:
>> > At 05:46 PM 3/17/2011, Lou Berger wrote:
...
>> >1) a real nit:
>> >I suspect that the <flow descriptor list> RBNF is broken, and
>> >[MULTI_FLOWSPEC] should be [ <MULTI_FLOWSPEC> ] .
> yep, sorry - this is obvious
>
>> >  (You might want to add a reference to 5511 too.)
> probably
>
>
>> >2) I could see this as a more generally applicable problem, in
>> >particular it could apply to the non-IntServ class types supported by
>> >RSVP (TSPEC/FLOWSPEC).  What do you think about having the MULT_xxSPEC
>> >objects being defined solely on the RSVP level (perhaps using
>> >subobjects) rather than as defined now which is a change to RSVP and
>> >IntServ?
> Hadn't thought about this before. We'll think about how this would
> work and if there are any gotchas.

Have you had any further thoughts?  I think this would have the real
benefit that it can apply to all flowspec types.

Lou

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Jul 2011 01:01:32 -0500

Lou

I've been pondering this since you first sent it. I can't find anyone 
that thinks this is a bad idea, but I also haven't found anyone that 
thinks this is a no-brainer either. I mean, the same logic will be 
needed because the same steps are needed to replace whatever is in 
the new MULTI_xxSPEC Object you propose.

I do have a concern - and that has to do with what to do with the 
existing MULTI_TSPEC text that has to go somewhere. I mean, is it 
within this same new draft that creates the MULTI_xxSPEC Object, or 
are they separate drafts, in which the MULTI_TSPEC is the first 
offering (in its own draft) for what goes into the MULTI_xxSPEC 
Object (framework)?

We also have an individual draft about a MULTI_PREEMPTION_PRI Object 
that extends RFC 3181 just as the MULTI_TSPEC extends 2210 (where the 
TSPEC is defined). Is that to be in another draft, or just one bigger 
draft since we know it's coming?

I'm thinking about the structure of the Object too, and I'm not sure about it.

I plan on having this be the basis for what I talk about Friday 
during the MULTI_TSPEC preso slot.

Do others have comments and/or inputs to this idea?

James