Subject: [tsvwg] RSVP and other thoughts

From: ken carlberg <[email-masked]>
Date: Thu, 12 Nov 2009 09:36:47 -0500

Lars,

I heard your comments from audio-land about the possibility of freezing future work on RSVP, in part because of lack of list discussion and developers, and I have to agree with the thought brought up by Lou that this decision (if it comes to pass) fosters the need to push RSVP into historic status. 

RSVP was designed to grow in the form of extensions, and if the Transport ADs shut down future extensions (regardless of the reason), then additional work needs to be done elsewhere.  However, I can't see how this can be done if the IETF still views itself as the owner/maintainer of the protocol.  And I don't agree that freezing new extensions doesn't mean that RSVP can't be used.  If one locks out a protocols inherent ability to grow/evolve, then its pretty much dead...if not now, then some point down the line.

(huge caveat: I was half asleep when listening because of the time zone difference, so my apologies if I'm not capturing the exact quotes, but I think the above covers the gist of the exchange).

I also sympathize with the head scratcher of minimal participation in TSV....for any effort that comes its way.  I think this is a function of the incredibly long process in standardization within the IETF these days (compared to 10-15 years ago), as well as the catch-all nature of the TSV wg and its having a lot of small interest groups involved (eg, SCTP, RSVP, diff-serv, etc) within one umbrella.  The recent work on the multi-TSPEC is the latest example of not much commentary from the peanut gallery (I may have been the only one to give a review -- and I have no connection with the effort).  But there are examples over the past few years of other efforts in TSV not related to RSVP that have also received very little feedback, with the chairs asking (pleading? :-) for more comments.  

-ken

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 12 Nov 2009 23:48:13 +0000

I would be really distressed if RFC 2205 went to Historic without the 
commitment to work on entirely rewriting RFC 3209 to include all of the 
relevant material. I don't believe there is any energy to do that work, so 
RFC 2205 must persist as is.

I share the concerns about the creeping additions to RSVP, but that is an 
issue for WG chairs and TSV ADs to work out whether there is consensus 
support to do the work and to publish the documents.

Whether the level of change in RSVP lately is within the TSV charter as 
currently written *is* a point for debate. Charter can be changed. New WGs 
can be formed. Doing stuff that is not on a WG charter is to be watched 
carefully.

Was that $0.06?

Adrian
----- Original Message ----- 
From: "ken carlberg" <[email-masked]>
To: "tsvwg" <[email-masked]>
Sent: Thursday, November 12, 2009 2:36 PM
Subject: [tsvwg] RSVP and other thoughts

Lars,

I heard your comments from audio-land about the possibility of freezing 
future work on RSVP, in part because of lack of list discussion and 
developers, and I have to agree with the thought brought up by Lou that this 
decision (if it comes to pass) fosters the need to push RSVP into historic 
status.

RSVP was designed to grow in the form of extensions, and if the Transport 
ADs shut down future extensions (regardless of the reason), then additional 
work needs to be done elsewhere.  However, I can't see how this can be done 
if the IETF still views itself as the owner/maintainer of the protocol.  And 
I don't agree that freezing new extensions doesn't mean that RSVP can't be 
used.  If one locks out a protocols inherent ability to grow/evolve, then 
its pretty much dead...if not now, then some point down the line.

(huge caveat: I was half asleep when listening because of the time zone 
difference, so my apologies if I'm not capturing the exact quotes, but I 
think the above covers the gist of the exchange).

I also sympathize with the head scratcher of minimal participation in 
TSV....for any effort that comes its way.  I think this is a function of the 
incredibly long process in standardization within the IETF these days 
(compared to 10-15 years ago), as well as the catch-all nature of the TSV wg 
and its having a lot of small interest groups involved (eg, SCTP, RSVP, 
diff-serv, etc) within one umbrella.  The recent work on the multi-TSPEC is 
the latest example of not much commentary from the peanut gallery (I may 
have been the only one to give a review -- and I have no connection with the 
effort).  But there are examples over the past few years of other efforts in 
TSV not related to RSVP that have also received very little feedback, with 
the chairs asking (pleading? :-) for more comments.

-ken

---

From: Lars Eggert <[email-masked]>
Date: Fri, 13 Nov 2009 17:17:29 +0900

Hi,

I'm beginning to realize that I was probably not entirely clear during the session. Let me respond to your points below and see if that clarifies things.

On 2009-11-12, at 23:36, ken carlberg wrote:
> I heard your comments from audio-land about the possibility of freezing future work on RSVP, in part because of lack of list discussion and developers

I do _not_ want to freeze future work on RSVP. TSVWG is chartered to maintain the protocol and may do small extensions, and I see no reason to eliminate this work item from the charter.

That said, the "multiple TSPEC" proposal in my current understanding is a pretty significant change to both RSVP and IntServ, and hence not something that the WG can decide to simply take on under the current charter work item. (I'm willing to be convinced that I'm misunderstanding the proposal.)

So at least currently, taking on this proposal would require rechartering TSVWG for doing some substantial new RSVP work, and for *that* I'd really like to see some significant energy from the RSVP implementors community. I haven't been seeing it in the past, and I'd frankly be surprised to see it in the future.

I also want to make it clear that I'm not singling out RSVP here - those of you in TSVWG will have heard me make similar arguments about SCTP, and over in other working groups there are other examples.

> , and I have to agree with the thought brought up by Lou that this decision (if it comes to pass) fosters the need to push RSVP into historic status. 

I hope the above clarifies why I disagreed with Lou at the meeting. Not doing major extensions to RSVP is *not* in any way the same as making it Historic.

Lars

---

From: Ashok Narayanan <[email-masked]>
Date: Fri, 13 Nov 2009 16:01:18 -0500

On Nov 13, 2009, at 11/13 3:17 AM, Lars Eggert wrote:

> Hi,
>
> I'm beginning to realize that I was probably not entirely clear  
> during the session. Let me respond to your points below and see if  
> that clarifies things.
>
>> I heard your comments from audio-land about the possibility of  
>> freezing future work on RSVP, in part because of lack of list  
>> discussion and developers
>
> I do _not_ want to freeze future work on RSVP. TSVWG is chartered to  
> maintain the protocol and may do small extensions, and I see no  
> reason to eliminate this work item from the charter.
>
> That said, the "multiple TSPEC" proposal in my current understanding  
> is a pretty significant change to both RSVP and IntServ, and hence  
> not something that the WG can decide to simply take on under the  
> current charter work item. (I'm willing to be convinced that I'm  
> misunderstanding the proposal.)

It's not clear to me that the fact that both RSVP and IntServ are  
being extended is sufficient grounds to raise the There are two  
additional ways to look at this, both of which are in disagreement  
with your view :-)

- One view is that the "multiple TSPEC" proposal is strictly an  
enhancement to IntServ, not RSVP. Flowspec computation, merging and  
propagation rules are part of IntServ. There is some blurring of the  
lines because RFC2205 and especially RFC2209 do talk about these rules  
for regular IntServ flowspecs, but I view that as duplication of  
information rather than sharing of a functional definition. Now,  
multiple preemption priority is a strict enhancement to RSVP and does  
not affect IntServ at all. You could take the view that these two  
drafts _in combination_ extend both RSVP and IntServ and that is out  
of charter. Does it change if the authors push one draft (multiple  
flowspec) all the way through to RFC before submitting the other draft  
(multiple preemption priority)? Isn't that just an artificial

- Another, diametrically opposed view is that IntServ as a concept is  
dead, and multiple TSPEC (even single TSPEC for that matter) is used  
in RSVP to carry flow information.  Therefore, changes to

>
> So at least currently, taking on this proposal would require  
> rechartering TSVWG for doing some substantial new RSVP work, and for  
> *that* I'd really like to see some significant energy from the RSVP  
> implementors community. I haven't been seeing it in the past, and  
> I'd frankly be surprised to see it in the future.

Actually there is plenty of energy in the "RSVP implementors"  
community; TSVWG doesn't see it because most of it is focused on MPLS/ 
TE and GMPLS/TE extensions for RSVP. The problem is this artificial  
separation of RSVP as part of TSVWG but RSVP/TE as part of CCAMP. The  
latest misadventure as a result of this separation is the overlap  
between ASSOCIATION object in CCAMP and RSID object in TSVWG. If we  
merge the RSID functionality into the ASSOCIATION object (as is the  
current proposal), then CCAMP will be producing a draft that includes  
some RSVP QoS-related functionality, which is strictly speaking part  
of TSVWG charter.

-Ashok

>
> I also want to make it clear that I'm not singling out RSVP here -  
> those of you in TSVWG will have heard me make similar arguments  
> about SCTP, and over in other working groups there are other examples.
>
>> , and I have to agree with the thought brought up by Lou that this  
>> decision (if it comes to pass) fosters the need to push RSVP into  
>> historic status.
>
> I hope the above clarifies why I disagreed with Lou at the meeting.  
> Not doing major extensions to RSVP is *not* in any way the same as  
> making it Historic.
>
> Lars

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 14 Nov 2009 16:29:35 +0100

Ashok,

You state here below:
> If we merge the RSID functionality into the ASSOCIATION object (as is
the  

> some RSVP QoS-related functionality, which is strictly speaking part  

The ASSOCIATION object is generically defined in RFC 4872. A-priori
nothing prevents extending the object with a new association type for
other "applications" in TSVWG (if charter allows and receives sufficient
support for it). In particular this object is not "G/MPLS-TE" specific
as it does not carry any information element preventing usage outside of
the "G/MPLS-TE" context. 

So, I do not understand why you consider that this extended usage of the
ASSOCIATION object must be performed in context of CCAMP exclusively ?
Can you pls clarify ?

Thanks,
-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ashok Narayanan
> Sent: Friday, November 13, 2009 10:01 PM
> To: Lars Eggert
> Cc: tsvwg
> Subject: Re: [tsvwg] RSVP and other thoughts
> 
>

---

From: Ashok Narayanan <[email-masked]>
Date: Sat, 14 Nov 2009 11:11:00 -0500

> ASSOCIATION object must be performed in context of CCAMP exclusively ?

Because the processing rules of that object may need to be changed,  
not just a new C-type extension. The current plan is to try and work  
the changes into draft-berger-ccamp-assoc.

-Ashok

---

From: Ashok Narayanan <[email-masked]>
Date: Sat, 14 Nov 2009 11:15:44 -0500

Hit send too early....

On Nov 13, 2009, at 11/13 4:01 PM, Ashok Narayanan wrote:

>> I do _not_ want to freeze future work on RSVP. TSVWG is chartered  
>> to maintain the protocol and may do small extensions, and I see no  
>> That said, the "multiple TSPEC" proposal in my current  
>> understanding is a pretty significant change to both RSVP and  
>> IntServ, and hence not something that the WG can decide to simply  
>> take on under the current charter work item. (I'm willing to be  
>> convinced that I'm misunderstanding the proposal.)
>
> lines because RFC2205 and especially RFC2209 do talk about these  
> rules for regular IntServ flowspecs, but I view that as duplication  
> of information rather than sharing of a functional definition. Now,  
> multiple preemption priority is a strict enhancement to RSVP and  
> does not affect IntServ at all. You could take the view that these  
> two drafts _in combination_ extend both RSVP and IntServ and that is  
> out of charter. Does it change if the authors push one draft  
> (multiple flowspec) all the way through to RFC before submitting the  
> other draft (multiple preemption priority)? Isn't that just an  
> artificial
>
> - Another, diametrically opposed view is that IntServ as a concept  
> is dead, and multiple TSPEC (even single TSPEC for that matter) is  
> used in RSVP to carry flow information.  Therefore, changes to

... Therefore, changes to TSPec format are really just RSVP changes. I  
personally don't agree with this view, but I've heard it articulated.

-Ashok

>> rechartering TSVWG for doing some substantial new RSVP work, and  
>> for *that* I'd really like to see some significant energy from the  
>> RSVP implementors community. I haven't been seeing it in the past,  
>> and I'd frankly be surprised to see it in the future.
>
> community; TSVWG doesn't see it because most of it is focused on  
> MPLS/TE and GMPLS/TE extensions for RSVP. The problem is this  
> artificial separation of RSVP as part of TSVWG but RSVP/TE as part  
> of CCAMP. The latest misadventure as a result of this separation is  
> the overlap between ASSOCIATION object in CCAMP and RSID object in  
> TSVWG. If we merge the RSID functionality into the ASSOCIATION  
> object (as is the current proposal), then CCAMP will be producing a  
> draft that includes some RSVP QoS-related functionality, which is  
> strictly speaking part of TSVWG charter.
>
> -Ashok
>
>>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 14 Nov 2009 17:26:11 +0100

> From: Ashok Narayanan [mailto:[email-masked]] 
> Sent: Saturday, November 14, 2009 5:11 PM
> To: PAPADIMITRIOU Dimitri
> Cc: Lars Eggert; tsvwg
> > So, I do not understand why you consider that this extended 
> usage of  
> > the

Its processing is defined by the Type of Association so I am not sure to
understand here if you want to modify an existing Type of define a new
one ? Clarification would be appreciated because I look at
"draft-berger-ccamp-assoc" and this doc. does not seem to exist only
"draft-berger-ccamp-assoc-info" exist but is not related to the present
discussion deals of the processing of this object in context of
protection and restoration.

Note: by type I mean the "Association Type" field.

-d.

> >> understanding

---

From: Ashok Narayanan <[email-masked]>
Date: Sat, 14 Nov 2009 12:44:49 -0500

On Nov 14, 2009, at 11/14 11:26 AM, PAPADIMITRIOU Dimitri wrote:

> one ?

Well, basic rules such as "present in the Path" or "present in the  
Resv" is what we would have to change in this case. Probably we could  
do this with the new C-Type but the results are always messy - "C-Type  
1 MUST be in the Path, C-Type 5 MUST be in the Resv" is not typically  
done in RSVP.

> Clarification would be appreciated because I look at

That's the draft; sorry I had the wrong name. Lou is going to consider  
extending that draft to include the functionality in draft-narayanan- 
tsvwg-rsvp-rsource-sharing

-Ashok

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 16 Nov 2009 13:07:43 +0100

Hi Lars,

Can you help us understand what the current charter really says about RSVP?

First, when you introduced the discussion in the WG re current charter coverage of RSVP, you quoted two of the three RSVP related sentences:
"Maintenance of the Resource Reservation Protocol (RSVP), which involves bug fixes to the RSVP specifications and their progression along the standards track. This work item may also include a small number of extensions to RSVP or advisory documents to address specific application scenarios. "

But a number of folks seem to have misread "a small number of extensions" into "a number of small extensions". I personally note that the charter scope does include "a small number of extensions to RSVP"  without attempting to classify those as small, medium or large.

Second, the 3rd RSVP-related sentence you did not quote in the WG is the following:
"In order to maintain stable specifications, additional work on RSVP in TSVWG requires Area Director approval."

This again suggests to me that additional work on RSVP is expected by the current charter, but this clarifies that the main gating factor is to not destabilize existing RSVP usage.

Based on this, my reading of the current charter is that:
	* RSVP extensions are clearly in scope
	* the criteria for accepting/rejecting new RSVP extension work should include:
		* making sure the extension addresses a specific application
		* making sure the WG is not biting more than it can chew (ie limiting the nb of extensions being worked on simultaneously)
		* making sure these extensions do not destabilize existing RSVP/RSVP-TE operations
	* the criteria for accepting/rejecting new RSVP extension work does not include:
		* whether the extension is small or large by whatever definition (which most likely depend on every individual) 

Could you clarify if this interpretation is not correct ?

Thanks

Francois

PS: I'm only focusing here on what the current charter actually says, and would like to keep discussions on potential changes to the charter separate.

---

From: <[email-masked]>
Date: Tue, 17 Nov 2009 10:08:44 -0000

To me the second sentence in the RSVP part of the charter reads as if it means:

"If any specific scenarios arise which weren't addressed by the original RSVP specifications then this charter allows a small number of extensions to be written to address those scenarios."

If you then take the 3rd sentence in context it was clearly intended to mean that the AD has to approve all such additional work (the small number of extensions in the previous charter) in order to ensure it doesn't destabilise the existing protocol. I think it is incorrect to try and interpret the 3rd sentence on its own as that takes it out of its context. If you were able to do that it would be possible to make a charter mean almost anything...

I think what this demonstrates is the degree of care that is needed on any charter and perhaps suggests a need to add "schedules" to the end of the charter clarifying what was actually meant...

Note, I am definitely NOT taking any sides in this debate (I don't know enough about RSVP to have any views...). I am just trying to help with interpreting what the charter actually means.

Toby

____________________________________________________________________ 
Toby Moncaster, Senior Researcher, Network Infrastructure Practice
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Francois Le Faucheur
> Sent: 16 November 2009 12:08
> To: Lars Eggert
> Cc: tsvwg
> Subject: [tsvwg] TSVWG - trying to understand what the charter really
> saysabout RSVP
> 
> Hi Lars,
> 
> First, when you introduced the discussion in the WG re current charter
> coverage of RSVP, you quoted two of the three RSVP related sentences:
> "Maintenance of the Resource Reservation Protocol (RSVP), which
> involves bug fixes to the RSVP specifications and their progression
> along the standards track. This work item may also include a small
> number of extensions to RSVP or advisory documents to address specific
> application scenarios. "
> 
> But a number of folks seem to have misread "a small number of
> extensions" into "a number of small extensions". I personally note that
> the charter scope does include "a small number of extensions to RSVP"
> without attempting to classify those as small, medium or large.
> 
> This again suggests to me that additional work on RSVP is expected by
> the current charter, but this clarifies that the main gating factor is
> to not destabilize existing RSVP usage.
> 
> 		* making sure the WG is not biting more than it can chew (ie
> limiting the nb of extensions being worked on simultaneously)
> 		* whether the extension is small or large by whatever
> definition (which most likely depend on every individual)
> 
> PS: I'm only focusing here on what the current charter actually says,
> and would like to keep discussions on potential changes to the charter
> separate.
> 
> during the session. Let me respond to your points below and see if that
> clarifies things.
> >
> maintain the protocol and may do small extensions, and I see no reason
> to eliminate this work item from the charter.
> >
> is a pretty significant change to both RSVP and IntServ, and hence not
> something that the WG can decide to simply take on under the current
> charter work item. (I'm willing to be convinced that I'm
> implementors community. I haven't been seeing it in the past, and I'd
> frankly be surprised to see it in the future.
> >
> those of you in TSVWG will have heard me make similar arguments about
> SCTP, and over in other working groups there are other examples.
> >

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 17 Nov 2009 11:55:39 +0100

> "If any specific scenarios arise which weren't addressed by the original RSVP specifications then this charter allows a small number of extensions to be written to address those scenarios."

Agreed.

> 
> If you then take the 3rd sentence in context it was clearly intended to mean that the AD has to approve all such additional work (the small number of extensions in the previous charter) in order to ensure it doesn't destabilise the existing protocol.

Just to avoid any confusion, my message below was not trying to suggest that the additional RSVP work does not need AD approval. I agree the text is very clear about that. My point was that the charter text recognizes that new RSVP work can indeed be taken on by the WG, conditioned by AD approval, such approval being guided by concerns of protocol stability.

So I think we have similar interpretation. No?

Thanks

Francois 

> I think it is incorrect to try and interpret the 3rd sentence on its own as that takes it out of its context. If you were able to do that it would be possible to make a charter mean almost anything...
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Nov 2009 08:19:59 -0500

Lars,
	Sorry about the late reply.  I think there is a difference in your mail 
from what I heard in session.  I thought I heard you say you were 
essentially unwilling to accept any new RSVP/IntServ work in the WG, and 
it was this that prompted my comment on moving RSVP to 'Historic'.  I 
now understand your position to be that this specific extension is 
beyond the scope of the charter, and that in order to progress it, the 
charter must be updated.  Is this correct?

I certainly understand and think it is reasonable for the WG, the chairs 
and the AD to have certain conditions that need to be met as part of any 
WG rechartering.  I also believe that it's important for the IETF to 
have a place where RSVP extensions (outside of the context of TE) can be 
defined.  If there is no such place, then I think the protocol is 
effectively deprecated.  If you feel there is insufficient support for 
Standards track work on non-TE RSVP extensions, there are other document 
tracks in the IETF that are available for WG documents.  Perhaps one of 
these would be more acceptable?

Lou

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Nov 2009 16:06:26 +0200

Hi,

> charter must be updated.  Is this correct?

based on my current understanding of the proposal, that is correct.

(I think the confusion resulted from me commenting that I wasn't particularly overwhelmed by the size and energy of the overall RSVP community that pushes work in TSVWG in this space, which basically consists of very few people, most of which come from a single vendor. This has made it often very difficult to adequately review even proposals that are much simpler than the current one. But I didn't mean to imply that we should eliminate RSVP maintenance as a TSVWG work item, just that it has been difficult to do it properly.)

> effectively deprecated.

As I said before, I see no reason to eliminate RSVP maintenance from the charter.

> If you feel there is insufficient support for 

That could be an option.

Lars

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Nov 2009 12:13:10 -0500

On 11/19/2009 9:06 AM, Lars Eggert wrote:
>[...]

Lars,
	I think the crux of this discussion is really to identify the process 
by which non-TE RSVP extensions are brought into and carried forward in 
the IETF.  It seems reasonable to me to have a strong filter (which may 
include WG charter changes) on what becomes a Proposed standard and what 
doesn't.  What is unreasonable, at least to me, is to have a process by 
which uncontested work cannot be published in any form.

Perhaps a WG policy which only allows for documents to progress as 
standards track when there is the "participation" of multiple 
implementers and uses Experimental (or informational) otherwise would be 
suitable?  This way an RFC can be used to support a particular function, 
and if this function becomes popular the document can be republished on 
the standards track.  Thoughts?

Independent of the particulars of the policy or process, I think it's 
time to address this long standing issue.

Thanks,
Lou

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Nov 2009 13:01:08 -0600

At 11:13 AM 11/19/2009, Lou Berger wrote:

>         I think the crux of this discussion is really to identify 
> the process by which non-TE RSVP extensions are brought into and 
> carried forward in the IETF.  It seems reasonable to me to have a 
> strong filter (which may include WG charter changes) on what 
> becomes a Proposed standard and what doesn't.

<speaking as an individual>

I agree with this above.

>What is unreasonable, at least to me, is to have a process by which 
>uncontested work cannot be published in any form.
>
>implementers and uses Experimental (or informational) otherwise 
>would be suitable?

Asking for multiple implementations before a document can get its RFC 
number will take the status of that doc directly to Draft Standard, right?

;-)

This seems like a high bar to set for protocol one might want to 
single out, such as RSVP -- whose core RFC (2205) is only PS (for the 
last 12 years).

This strategy seems problematic to me.  It appears that in a grab-bag 
WG (which TSVWG is) there is a proposal to single out a protocol and 
make any extension to that protocol have to have multiple 
implementers.  I have to ask, why not just make any base protocol 
within this grab-bag have to have multiple implementers before an RFC 
number can be assigned?  Then, why limit this to a grab-bag WG.  Why 
not apply this to SIP (which is only a PS)? or LoST? or Geopriv?

Perhaps we then will need to define what multiple implementations 
are. Does this apply to only 100% compliant implementations (2 or 
more) to be comsidered "multiple"?

The point I'm making - is that this is a slippery slope.

There are 2 standards track RSVP extensions with the IESG right now. 
Do they fall under this new proposal?

>This way an RFC can be used to support a particular function, and if 
>this function becomes popular the document can be republished on the 
>standards track.  Thoughts?
>
>Independent of the particulars of the policy or process, I think 
>it's time to address this long standing issue.

I agree with Lou that this has been a "let's hide this in the corner" 
issue since before I became WG chair, then wasn't solved by the 
previous ADs (meaning this is not the fault of Lars and 
Magnus).  That said, it's time, now that there are more than a few 
gaps being discovered in the RSVP suite of RFCs that there are more 
and more drafts being written to address those gaps.

I'm not the biggest fan of this work being done outside of TSVWG, but 
if this work needs to be considered for a group outside TSVWG, that 
possibility should be discussed as well (if others agree).

James
<as an individual>

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Nov 2009 14:33:27 -0500

A few comments:
- I think you may have missed that my suggestion was WG wide, not RSVP 
specific.

- Some areas use the multiple-implementation bar for PS, at least for 
major new protocols or protocol modifications.  For example, the CCAMP 
WG progressed RFC 5467 as experimental due to lack of implementations. 
It looks like we'll be soon revisiting its status as MPLS-TP requires 
this function.  Like so many things at the IETF the WG chairs and AD 
make the call as to which track is appropriate. (BTW this case predates 
me as ccamp co-chair.)

- what group are you thinking about when you say "a group outside TSVWG"?

Lou

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Nov 2009 14:17:14 -0600

Lou

I understood you meant WG wide, I just didn't focus on anything other 
than RSVP in the note (at least within TSV).

I think the fact that there are several IDs with the IESG about RSVP 
right now could cause them to be impacted if we change to a "there 
needs to be multiple implementaitons for us (re: TSVWG) to consider 
assigning an RFC number to each.

I think the vagueness of whether or not IntServ can be updated based 
on the existing charter is valid. Therefore this MULTI_TSPEC/FLOWSPEC 
doc is going to be the one that helps the WG define whether the 
existing charter can do this type of work is what it is. I'm not 
thrilled as an editor of the doc (because IntServ isn't explicitly 
called out in the charter - but I read that as binding RSVP & IntServ 
together in the charter), but I understand this as a WG 
chair.  IntServ probably needs to be called out for this ID to progress.

Then we get into the "is this protocol/mechanism maintenance or a 
major extension discussion".  This is less clear to me, even as a WG 
chair - as I see the ability to send multiple copies of an existing 
piece of information (i.e., the TSPEC and FLOWSPEC already exist), 
and not a new object with new information - as not being a major change.

What group am I thinking other than TSVWG?  Perhaps a new WG (which 
will have to have a BoF first) ... this has been discussed over the 
many years I've been involved in TSVWG, not just when I've been chair.

James

At 01:33 PM 11/19/2009, Lou Berger wrote:

>A few comments:
>- I think you may have missed that my suggestion was WG wide, not 
>RSVP specific.
>
>- Some areas use the multiple-implementation bar for PS, at least 
>for major new protocols or protocol modifications.  For example, the 
>CCAMP WG progressed RFC 5467 as experimental due to lack of 
>implementations. It looks like we'll be soon revisiting its status 
>as MPLS-TP requires this function.  Like so many things at the IETF 
>the WG chairs and AD make the call as to which track is appropriate. 
>(BTW this case predates me as ccamp co-chair.)
>

---

From: Ping Pan <[email-masked]>
Date: Thu, 19 Nov 2009 12:31:45 -0800

Agree with many argument on this thread.

To my knowledge, RSVP/IntServ have been implemented and deployed for
applications other than MPLS. One application comes to mind is cable.

Just curious, is there any survey written somewhere describing how
RSVP/IntServ have been used, and which parts of the protocols have been
used?

Thanks!

- Ping

On Thu, Nov 19, 2009 at 12:17 PM, James M. Polk <[email-masked]> wrote:

> Lou
>
> I understood you meant WG wide, I just didn't focus on anything other than
> RSVP in the note (at least within TSV).
>
> I think the fact that there are several IDs with the IESG about RSVP right
> now could cause them to be impacted if we change to a "there needs to be
> multiple implementaitons for us (re: TSVWG) to consider assigning an RFC
> number to each.
>
> I think the vagueness of whether or not IntServ can be updated based on the
> existing charter is valid. Therefore this MULTI_TSPEC/FLOWSPEC doc is going
> to be the one that helps the WG define whether the existing charter can do
> this type of work is what it is. I'm not thrilled as an editor of the doc
> (because IntServ isn't explicitly called out in the charter - but I read
> that as binding RSVP & IntServ together in the charter), but I understand
> this as a WG chair.  IntServ probably needs to be called out for this ID to
> progress.
>
> Then we get into the "is this protocol/mechanism maintenance or a major
> extension discussion".  This is less clear to me, even as a WG chair - as I
> see the ability to send multiple copies of an existing piece of information
> (i.e., the TSPEC and FLOWSPEC already exist), and not a new object with new
> information - as not being a major change.
>
> What group am I thinking other than TSVWG?  Perhaps a new WG (which will
> have to have a BoF first) ... this has been discussed over the many years
> I've been involved in TSVWG, not just when I've been chair.
>
> James
>
>
>> major new protocols or protocol modifications.  For example, the CCAMP WG
>> progressed RFC 5467 as experimental due to lack of implementations. It looks
>> like we'll be soon revisiting its status as MPLS-TP requires this function.
>>  Like so many things at the IETF the WG chairs and AD make the call as to
>> which track is appropriate. (BTW this case predates me as ccamp co-chair.)
>>
>>>>> As I said before, I see no reason to eliminate RSVP maintenance
>>>>>
>>>> >from the charter.
>>>>
>>>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Nov 2009 15:37:09 -0500

James,
	I don't see a reason to link a policy guiding future work to impact 
work that is already progressing in the WG.  If such a policy was made 
retroactive, it is far less likely to be accepted which would leave us 
in the current (IMO) untenable state with never ending debate on what 
the charter allows and where/if a particular extension fits.  Of course, 
this is up to the chairs and AD.  If the suggested policy doesn't help, 
let's drop it.

A new WG would be fine, but will you get enough support/momentum?  Given 
the current level of activity in TSV, it seems not.

Lou

On 11/19/2009 3:17 PM, James M. Polk wrote:
> called out in the charter - but I read that as binding RSVP&  IntServ

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Nov 2009 14:57:39 -0600

At 02:37 PM 11/19/2009, Lou Berger wrote:
>James,
>         I don't see a reason to link a policy guiding future work 
> to impact work that is already progressing in the WG.  If such a 
> policy was made retroactive, it is far less likely to be accepted 
> which would leave us in the current (IMO) untenable state with 
> never ending debate on what the charter allows and where/if a 
> particular extension fits.  Of course, this is up to the chairs and 
> AD.  If the suggested policy doesn't help, let's drop it.

I'm open to the discussion, certainly.

>A new WG would be fine, but will you get enough 
>support/momentum?  Given the current level of activity in TSV, it seems not.

3 years ago I would have said the same thing about (what became) PCN 
... which had only a few strong supporters (ironically, they were 
mostly from one company as well).  I'm not saying splitting off RSVP 
from TSVWG should happen, or if this might be actively proposed. I 
just commented about gauging the level of support in a grab-bag WG 
has always been difficult -- as chair of the WG, this is difficult 
for all of our protocols or mechanisms (basically all 6 of them).

James

---

From: ken carlberg <[email-masked]>
Date: Thu, 19 Nov 2009 16:32:57 -0500

Lou,

> Perhaps a WG policy which only allows for documents to progress as standards track when there is the "participation" of multiple implementers and uses Experimental (or informational) otherwise would be suitable? This way an RFC can be used to support a particular function, and if this function becomes popular the document can be republished on the standards track.  Thoughts?

in principle, I'd love to go back to the (roughly) pre-'95 days and have some kind of implementation nudge to gauge actual interest/effort in a proposed idea.  But I would only feel comfortable *IF* it was IETF-wide instead of just a WG-specific policy.    on the opposite side of the spectrum, there are some WGs that are pumping out a whole lot of stuff,  where short-term history seems to show that a good portion of it goes by the wayside.  The implementation model would probably help cut down that effort as well.  However, doing this on a WG-only basis makes me feel very uncomfortable.

-ken

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Nov 2009 17:04:02 -0500

Ken,

Some areas already essentially operate with such a stance.  They're not 
perfect, but there are generally predictable ways to progress/kill 
documents.

BTW If there's no "implementation nudge to gauge actual 
interest/effort", i.e., demand, for an extension why would it be a 
candidate for a standards track RFC?

Lou

---

From: ken carlberg <[email-masked]>
Date: Thu, 19 Nov 2009 17:20:04 -0500

Lou,

> BTW If there's no "implementation nudge to gauge actual interest/effort", i.e., demand, for an extension why would it be a candidate for a standards track RFC?

well, I'm going to avoid citing specific examples in public, and the ones that came to mind that prompted my previous statement actually come from other working groups.  

but other things to keep in mind is that in many instances, quite a number of vendors will not provide even a prototype unless the draft becomes an RFC.  And quite a number of providers won't consider efforts (outside of absolute critical work) unless it is an RFC.  

outside of that, I'm not qualified to explain the in-depth business decisions of vendors/providers :-)

-ken

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Nov 2009 18:11:01 -0500

Ken,
	I understood your comment to also refer to this WG.  I agree that 
there's no need to discuss other WG (mis)behavior in this thread.  I 
understand the standards chicken and egg problem, but "participation" 
can come in many forms and doesn't need to include implementation before 
an RFC is published.  Also, IMO, if there's no one planning to implement 
a document then it should not be on the standards track.  (An RFC on 
another track is just fine.)  Just my personal opinion...

Lou

---

From: Bob Braden <[email-masked]>
Date: Fri, 20 Nov 2009 12:01:30 -0800

>>> these would be more acceptable?
And there is a non-IETF track, the independent submission stream, in 
which you can publish RSVP extensions as Informational documents.

RSVP was explicitly designed to be easily extensible, from a technical 
viewpoint. It is too bad that the working group process is unable to 
take effective advantage of that fact.

Bob Braden

>> That could be an option.
> >
> > Lars
>
> Lars,
>     I think the crux of this discussion is really to identify the 
> process by which non-TE RSVP extensions are brought into and carried 
> forward in the IETF.  It seems reasonable to me to have a strong 
> filter (which may include WG charter changes) on what becomes a 
> Proposed standard and what doesn't.  What is unreasonable, at least to 
> me, is to have a process by which uncontested work cannot be published 
> in any form.

---

From: Lou Berger <[email-masked]>
Date: Fri, 20 Nov 2009 15:30:59 -0500

> take effective advantage of that fact.

Bob,

I'm in complete agreement with this point.  Although, I do think that as 
a PS protocol extensions to the protocol should at least be reviewed by 
the/a WG before being issued as an RFC.

Lou

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 21 Nov 2009 08:53:14 +0000

We seem to have a lot of email about RSVP, but right now, we also have a 
draft on RSVP security groupkeying that is currently in last call.

Please send comments to the list either in support or against 
progressing this draft. If there is not sufficient support, the Chairs 
could return this to the group for further work. Fortunately, James set 
a last call deadline that was longer than normal, and there is still a 
week to go.

If you have read this and think the document is useful, complete, or 
needs further work, then please do say.

Gorry

---

From: ken carlberg <[email-masked]>
Date: Mon, 23 Nov 2009 07:59:19 -0500

Hi Gorry,

I've read the draft in detail and have given a detailed set of comments in the past.  I feel comfortable with the changes made in response to these comments and support its advancement to the IESG for their consideration.

Also, I recall that several folks have sent comments on this draft, so my feeling would be that if there are no more comments, that would actually be a good sign that its good to go.  I'd feel uncomfortable if there was a need to have folks reaffirm support during Last Call periods.  On the other hand, its a great time to awaken people and see if there are any last minute concerns.

cheers,

-ken

On Nov 21, 2009, at 3:53 AM, Gorry Fairhurst wrote:

> 
> We seem to have a lot of email about RSVP, but right now, we also have a draft on RSVP security groupkeying that is currently in last call.
> 
> Please send comments to the list either in support or against progressing this draft. If there is not sufficient support, the Chairs could return this to the group for further work. Fortunately, James set a last call deadline that was longer than normal, and there is still a week to go.
> 
> If you have read this and think the document is useful, complete, or needs further work, then please do say.
> 
> Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 23 Nov 2009 13:10:35 +0000

Thanks Ken,

If people have reviewed the previous version, you can see the 
differences here:
http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/draft-ietf-tsvwg-rsvp-security-groupkeying-05-from-04.diff.html

We'd be happy to see others send a short note saying "I read the last 
version and I think this is now ready for publication."

Best wishes,

Gorry

---

From: Brian Weis <[email-masked]>
Date: Mon, 30 Nov 2009 10:50:35 -0800

On Nov 23, 2009, at 5:10 AM, Gorry Fairhurst wrote:

> We'd be happy to see others send a short note saying "I read the  
> last version and I think this is now ready for publication."

After reviewing the differences link above (thanks, Gorry!), I believe  
this version is ready for publication.

Thanks,
Brian

>
> Best wishes,
>
> Gorry
>
> ken carlberg wrote:
>> Hi Gorry,
>> I've read the draft in detail and have given a detailed set of  
>> comments in the past.  I feel comfortable with the changes made in  
>> response to these comments and support its advancement to the IESG  
>> for their consideration.
>> Also, I recall that several folks have sent comments on this draft,  
>> so my feeling would be that if there are no more comments, that  
>> would actually be a good sign that its good to go.  I'd feel  
>> uncomfortable if there was a need to have folks reaffirm support  
>> during Last Call periods.  On the other hand, its a great time to  
>> awaken people and see if there are any last minute concerns.
>> cheers,
>> -ken
>>> We seem to have a lot of email about RSVP, but right now, we also  
>>> have a draft on RSVP security groupkeying that is currently in  
>>> last call.
>>>
>>> progressing this draft. If there is not sufficient support, the  
>>> Chairs could return this to the group for further work.  
>>> Fortunately, James set a last call deadline that was longer than  
>>> normal, and there is still a week to go.
>>>
>>> If you have read this and think the document is useful, complete,  
>>> or needs further work, then please do say.
>>>
>>> Gorry
>

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Sheela Rowles (sheela)" <[email-masked]>
Date: Mon, 30 Nov 2009 11:28:03 -0800

I've reviewed the latest version, and believe the draft is read to go
forward for publication. 

Thanks,
Sheela

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Weis (bew)
Sent: Monday, November 30, 2009 10:51 AM
To: tsvwg WG
Subject: Re: [tsvwg] RSVP Security Group Keying (was Re: RSVP - Last
CallReminder)

> If people have reviewed the previous version, you can see the  
http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeyin
g/draft-ietf-tsvwg-rsvp-security-groupkeying-05-from-04.diff.html

Thanks,
Brian