TSVWG Adoption of draft-polk-tsvwg-intserv-multiple-tspec

This email confirms the adoption of the above draft by TSVWG as a work 
item. Authors please prepare a draft -00 working group ID including
the comments received during the WG adoption call.

New name: draft-ietf-tsvwg-intserv-multiple-tspec

This document received postive support by the WG, and noissues were noted 
about its suitability for adoption. A set of reviewers have been be 
identified who will provide feedback duing the WG/IETF process.

Best wishes,

Gorry Fairhurst
(tsvwg Chair)

Re: New 48 hour LC on draft-ietf-tsvwg-sctpsocket

TSVWG

Having received no comments one way or the other, 
the chairs call (that silence as) WG acceptance 
of the changes, therefore this mini-LC is 
concluded and the draft will progress towards the IESG as its next step.

James & Gorry
TSVWG Chairs

At 10:30 PM 6/28/2011, James M. Polk wrote:
>TSVWG
>
>Michael Tüxen discovered a few bugs when 
>implementing this SCTP Socket API against -29 of 
>this draft.  The chairs are issuing a VERY SHORT 48 hour WGLC (details below).
>
>Here is the complete list (including the issues earlier reported):
>
>(NOTE: the "I" below is from Michael)
>
>(1) The list in section 8 for the socket options supported by sctp_opt_info()
>     is outdated. It should be updated to be consistent with the current doc.
>     I consider this purely editorial.
>(2) The description of SCTP_LOCAL_AUTH_CHUNKS is missing a statement regarding
>     the special assoc ids. It should be added.
>     I consider this purely editorial.
>(3) It should be made clear in section 8.1.20 that the sctp_data_io_event
>     is deprecated.
>     I consider this purely editorial.

Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support

CALL FOR PAPERS

2nd International Workshop on Protocols and Applications with Multi-Homing 
Support (PAMS 2012)
In conjunction with the 26th IEEE International Conference on Advanced 
Information Networkingand Applications (AINA 2012)
Fukuoka, Japan, March 26-29, 2012
http://tdrwww.iem.uni-due.de/pams2012.html

The intent of our workshop is to bring together people from research and
industry, in order to provide a discussion forum for state-of-the-art topics
related to multi-homing on Network, Transport, Session and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session
(with short presentations) to introduce preliminary ideas as well as work in
progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support

agenda slot for Aggregated RSVP over PCN

Hi Steve, Hi Gorry, Hi James

Please note that before tomorrow's deadline, I will submit the following
draft, which I would also like to present during the pcn and tsvwg
meetings.

Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 and
                IPv6 Reservations over PCN domains
            draft-karagiannis-pcn-tsvwg-RSVP-PCN-00

It will be great if I could get for each of the meetings (PCN and tsvwg)
a 20 minutes agenda slot.

Best regards,
Georgios

uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-00

Hi all,

I have just uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-00, see:
http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-00.txt

Filename: draft-karagiannis-pcn-tsvwg-rsvp-pcn
Revision: 00
Title: Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And
IPv6 Reservations over PCN domains
Creation date: 2011-07-04
WG ID: Individual Submission
Number of pages: 19

Abstract:
This document specifies the extensions to the Aggregated RSVP
[RFC3175] for support of the PCN Controlled Load (CL) and Single
Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification.

Comments are welcome!

It will be great if I could get for each of the meetings (pcn and tsvwg)
a 20 minutes agenda slot to present this draft!

Best regards,
Georgios

On 7/3/2011, "Georgios Karagiannis" <karagian <at> cs.utwente.nl> wrote:

>Hi Steve, Hi Gorry, Hi James

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

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 

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

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.

Re: I-D Action: draft-nishida-tsvwg-sctp-failover-03.txt

Hello folks,

We've just submitted the new version of sctp failover draft in order
to keep the doc alive.
Please give us feedbacks to proceed. We'll really appreciate your comments.

Thanks,
--
Yoshifumi Nishida
nishida <at> sfc.wide.ad.jp

2011/7/6  <internet-drafts <at> ietf.org>:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>        Title           : Quick Failover Algorithm in SCTP
>        Author(s)       : Yoshifumi Nishida
>                          Preethi Natarajan
>        Filename        : draft-nishida-tsvwg-sctp-failover-03.txt
>        Pages           : 15
>        Date            : 2011-07-06
>
>   One of the major advantages in SCTP is supporting multi-homing
>   communication.  If a multi-homed end-point has redundant network
>   connections, SCTP sessions can have a good chance to survive from
>   network failures by migrating inactive network to active one.
>   However, if we follow the SCTP standard, there can be significant
>   delay for the network migration.  During this migration period, SCTP
>   cannot transmit much data to the destination.  This issue drastically
>   impairs the usability of SCTP in some situations.  This memo
>   describes the issue of SCTP failover mechanism and discuss its

Re: draft-ietf-tsvwg-source-quench: SHOULD NOT vs. MUST NOT

Why isn't it:

	SHOULD NOT send

	MUST be ignored on receipt

The latter is much more important, isn't it?

Joe

On 6/22/2011 6:20 AM, Scott O. Bradner wrote:
> if one wanted to be anal one could say that "new implementations MUST NOT...." but
> I expect just saying MUST NOT wold be understood to apply to software created after
> the RFC was published
>
> Scott
>
> On Jun 22, 2011, at 8:54 AM, Scott Brim wrote:
>
>> For example, if you're allowing for existing implementations.
>

Saratoga reliable transport protocol