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

"James M. Polk" <jmpolk@cisco.com> Wed, 27 July 2011 06:01 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD97721F8782 for <tsvwg@ietfa.amsl.com>; Tue, 26 Jul 2011 23:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK-v0n23q+7r for <tsvwg@ietfa.amsl.com>; Tue, 26 Jul 2011 23:01:36 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D902F21F8781 for <tsvwg@ietf.org>; Tue, 26 Jul 2011 23:01:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5112; q=dns/txt; s=iport; t=1311746496; x=1312956096; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=UxO5d2aG8iWMtkeGV4XWIcWp39f70CB3x3JwGUlWIgs=; b=gdWeASQ4Jc2go/Lk4wHq7dVK3Gne6HFX+CrNQvtxbb9dOvwEhLYB9yKZ TvlSatubUJHLyzZ8Sh0Qti6EYfhMReRkIkTfIpDaB8oUp7w9vAfo3MJz6 45WP8P+KLvIhDbRjAiZKYbp7gDtZJ+oyi12N9jUNbcK2a5l2XXioz8mbJ 8=;
X-IronPort-AV: E=Sophos;i="4.67,274,1309737600"; d="scan'208";a="6800775"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2011 06:01:35 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-vpn-client-10-89-7-202.cisco.com [10.89.7.202]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6R61Y1U002314; Wed, 27 Jul 2011 06:01:34 GMT
Message-Id: <201107270601.p6R61Y1U002314@rcdn-core2-1.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 27 Jul 2011 01:01:32 -0500
To: Lou Berger <lberger@labn.net>, "James M. Polk" <jmpolk@cisco.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: draft-ietf-tsvwg-intserv-multiple-tspec-00 submitted
In-Reply-To: <4E14A909.4090900@labn.net>
References: <201107040017.p640HLc0031104@mtv-core-1.cisco.com> <4E14A909.4090900@labn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 06:01:36 -0000

At 01:27 PM 7/6/2011, Lou Berger wrote:
>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

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


>Lou
>
>On 7/3/2011 8:17 PM, James M. Polk wrote:
> > 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
> >> I-D-Announce@ietf.org
> >> 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
> >
> >
> >
> >
> >