Re: draft-polk-tsvwg-intserv-multiple-tspec-06

[Lou Berger <[e-mail]>]

I too think this is useful work and worth bringing into the WG.

Authors,

I have some comments/questions that can be addressed as the draft moves
forward (and don't need discussing if the draft isn't):

1) a real nit:
I suspect that the <flow descriptor list> RBNF is broken, and
[MULTI_FLOWSPEC] should be [ <MULTI_FLOWSPEC> ] .  (You might want to
add a reference to 5511 too.)

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?

Lou

PS I'm on the rsv-dir mailing list, but not listed on the web page so
have no idea if this means this is a comment as a directorate member or not.

PPS I won't be in the Prague session as I'll be chairing a WG at the
same time, but do support this work as a WG document if the topic comes up.


On 3/17/2011 10:16 AM, Bruce Davie wrote:
> 
> On Mar 17, 2011, at 4:29 AM, Gorry Fairhurst wrote:
> 
>>
>> I'm happy to discuss the future steps for this draft.
>>
>> I'll also take an action to check the status and then seek help from the RSVP directorate, the last note I saw from rsv-dir was 09/11/2010.
>>
> 
> You'll note that Fred recently posted my note from Nov 1, 2010, and Scott Bradner just commented as a directorate member.
> 
> So, the 3 directorate members who have commented are in favor of adopting this draft.
> 
> Bruce
> 
>> I'll also try to sumarise where I see this draft has reached. I can't do this today though.
>>
>> Gorry
>>
>> -------- Original Message --------
>> Subject: Re: draft-polk-tsvwg-intserv-multiple-tspec-06
>> Date: Wed, 16 Mar 2011 15:23:32 -0700
>> From: Fred Baker <[e-mail]>
>> To: ken carlberg <[e-mail]>
>> CC: tsvwg <[e-mail]>
>>
>>
>> On Mar 16, 2011, at 10:56 AM, ken carlberg wrote:
>>
>>> hello,
>>>
>>> my understanding is that the decision is still open as to whether this individual draft should become a working group draft.  I'd like to express my interest in making that migration.  My first comments on the draft came way back at the IETF-stockholm meeting in '09, where I brought up questions about multicast.  The current draft satisfies these questions, and other comments I have made since then.  I think this effort is properly baked for acceptance as a working group draft.
>>>
>>> But perhaps more importantly, I very much like its focus on optimization.  The bulk of the work we come across at the IETF either introduces new stuff, or augmentations to existing efforts.  Its refreshing to see work that focuses on optimizing something we already have.
>>>
>>> my 2 cents,
>>>
>>> -ken
>>
>> I think a relevant note is:
>>
>> On Nov 1, 2010, at 4:14 PM, Bruce Davie wrote:
>>> On these 2 drafts:
>>> On Oct 26, 2010, at 8:29 AM, Gorry Fairhurst wrote:
>>>
>>>> draft-polk-tsvwg-intserv-multiple-tspec
>>>>    RSVP directorate to be consulted.
>>>>    WG interest in this topic recorded at IETF-78.
>>>>    Charter update would be needed to progress this work.
>>>>    5 Reviews needed to determine energy/technical direction.
>>>>    Author will update -04.
>>>>    New revision expected.
>>>>
>>>> draft-lefaucheur-tsvwg-rsvp-multiple-preemption
>>>>    RSVP directorate to be consulted.
>>>>    WG needs to assess if this topic should be a work item.
>>>
>>> Two members of the RSVP directorate (myself and Lixia) have read these drafts and support their adoption by the WG. Below are some specific comments that I sent to the chairs, but I failed to send earlier to the WG. I believe at least one more directorate member has read these drafts but I've not received feedback one way or another about adoption from other directorate members.
>>
>> It would be good to know whether other members of the RSVP Directorate have commented. If there has been a charter discussion, I have managed to miss it.
>>
>> As to the draft itself, I think there is reason to support it, as we now have multi-rate codecs that can interact with it; rather than firing up, disturbing competing traffic to a degree that the codec data experiences loss and other traffic presumably does as well, and then backing off to a more acceptable rate (which is what rate-adaptive codecs do), it would be nice of the network could say "that will happen if you choose this rate, but if you choose this lower rate you will be better off." Having multiple T-Specs gives the network the option of making that choice on the first pas rather than taking binary decisions on multiple sequential decision steps.
>>
>>
> 
> 
> 
> 
>