Subject: [tsvwg] What's a minor vs major change to RSVP ?

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 12 Nov 2009 16:20:14 +0100

Hi

Following the discussion during this TSVWG meeting about what's a minor
and a major change to RSVP, the boundary condition seems to be: change
to RFC 1633 and 2205. 

The current charter states:

(B) 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. In order to maintain stable
specifications, additional work on RSVP in TSVWG requires Area
Director approval. 

Henee, I'd ask to the TSV chairs to include this distinction as part of
the charter. This would prevent any further "confusion" on what's a
minor vs major change to RSVP. 

Thanks,
-dimitri.

---

From: ken carlberg <[email-masked]>
Date: Thu, 12 Nov 2009 11:07:52 -0500

so, from your perspective and based on the passage you cite, does the multi-tspec draft constitute a minor or major change to RSVP?  The draft defines a single extension.

-ken

On Nov 12, 2009, at 10:20 AM, PAPADIMITRIOU Dimitri wrote:
> Hi
> 
> Following the discussion during this TSVWG meeting about what's a minor and a major change to RSVP, the boundary condition seems to be: change to RFC 1633 and 2205.
> 
> Henee, I'd ask to the TSV chairs to include this distinction as part of the charter. This would prevent any further "confusion" on what's a minor vs major change to RSVP.
> 
> Thanks, 
> -dimitri.
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Nov 2009 13:39:26 -0600

At 10:07 AM 11/12/2009, ken carlberg wrote:
>so, from your perspective and based on the passage you cite, does 
>the multi-tspec draft constitute a minor or major change to 
>RSVP?  The draft defines a single extension.

<with my author hat on>

More towards Dimitri, but also to the WG

Please keep in mind, this draft only defines a new optional *and* 
fully backwards compatible part to the <sender descriptor> and FLOWSPEC.

The only "update to RFC 2205" (RSVPv1) is to just carry the piece of 
information, but not do anything with it.

It's the "update to RFC2210" (IntServ) where the functionality is, 
where the parts within the <sender descriptor> and FLOWSPEC are acted 
upon.  But this ID doesn't add a totally new Object to IntServ. The 
ID allows more than one value of an existing Object to exist, as an 
efficiency towards reservation set-up time (i.e., reducing the RTT to 
set up the reservation).

Again, we made this fully backwards compatible by taking advantage of 
the existing principle of "ignore what you don't understand" within 
RSVP and IntServ.

Personally, I have never considered this ID to be a major extension. 
Defining a completely new Object with completely new functionality 
would be more towards being a major extension.  This ID doesn't meet 
that threshold IMO.

I am willing to admit, for those familiar with the ID, do you 
remember Options 1 and 2?  See the appendix in -02 to see part of 
that discussion. Version -01 had a more verbose appendix on these two 
other options.

The old "Option#2" would have been a much more radical change to RSVP 
and IntServ because it would have broken all backwards 
compatibility.  I can see Lars having taken his stance if Option#2 
were the only choice.

But the IETF74 (San Francisco) we went into great detail about all 
the options, and the WG decided to go with choice that had the least 
impact on existing implementations.

James
<with my author hat on>

>>Following the discussion during this TSVWG meeting about what's a 
>>minor and a major change to RSVP, the boundary condition seems to 
>>be: change to RFC 1633 and 2205.
>>
>>Henee, I'd ask to the TSV chairs to include this distinction as 
>>part of the charter. This would prevent any further "confusion" on 
>>what's a minor vs major change to RSVP.
>>
>>Thanks,
>>-dimitri.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Nov 2009 13:53:07 -0600

>be: change to RFC 1633 and 2205.

Dimitri

I authored RFC 4495 (Reservation Bandwidth Reduction), which updated 
RFC 2205 - by preventing a complete reservation to be torn down if 
only a part of the BW from it is needed to establish a new 
reservation.  This necessitated a new ResvErr code to be created, specifically

         ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)

to facilitate this extension's behavior.

Because this RFC updated RFC 2205, would you consider that to be a 
"major extension" that you would want the TSVWG chairs to make as the 
distinction?

There are other extensions I could have used as an example here, 
specifically any other one that I didn't author, but it appears to me 
that you want the distinction to be if the first page of the document 
states whether or not this

         updates RFC 2205 or 1633

as your bar.  Am I characterizing this correctly?

I want to understand exactly what you are saying in your recommendation below.

James
<this time with my chair hat on>

>Henee, I'd ask to the TSV chairs to include this distinction as part 
>of the charter. This would prevent any further "confusion" on what's 
>a minor vs major change to RSVP.
>
>Thanks,
>-dimitri.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 12 Nov 2009 21:27:58 +0100

James, 

To clarify I refer by RFC1633 to IntServ and thus 
implicitly to the usage of RSVP (2205) for IntServ.

Thanks,
-dimitri.

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: Thursday, November 12, 2009 8:39 PM
> To: ken carlberg; PAPADIMITRIOU Dimitri
> Cc: [email-masked]
> Subject: Re: [tsvwg] What's a minor vs major change to RSVP ?
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 12 Nov 2009 22:08:40 +0100

James, 

> Sent: Thursday, November 12, 2009 8:53 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]

Not only. 

Reason_1 (to be clear in terms of extensions: ext. to 2205): 

as detailed in Section 3:
" For the PATH message, the focus of this document is to modify the
   <sender_descriptor> in such a way to include more than one traffic
   specification.  This solution does this by retaining the existing
   SENDER_TSPEC object above, highlighted by the '^^^^' characters, and
   complementing it with a new optional MULTI_TSPEC object to convey
   additional traffic specifications in this PATH message. No other
   object within the PATH message is affected by this IntServ
   extension."

and in Appendix:
"   For the PATH message, the focus of this document is with what to do
   with respect to the <SENDER_TSPEC> above, highlighted by the '^^^^'
   characters. No other object within the PATH message will be affected
   by this IntServ extension."

and MULTI_FLOWSPECs object  

Reason_2 (to be clear in terms of extensions: ext. to 2210)

The addition of MULTI_TSPEC and MULTI_RSPEC parameters and rules (as
detailed in Section 3.1)

Reason 3 (idem)

The merging rules for the MULTI_FLOWSPECs (section 4.6 in the document)

So objects/messages and procedures are "affected" even if the proposed
changes are presented such as to expectedly ensure backward
compatibility. The last point is a necessary condition not a sufficient
condition "to extend RSVP per charter". 

These are imho the "protocol" arguments we could have also a discussion
about usage and effect on install base in terms of objective of these
extensions but at later stage if necessary.

Thanks,
-dimitri.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Nov 2009 15:13:07 -0600

<with my author hat on>

Then the fact that this ID doesn't update or even mention RFC 1633, 
rather RFC2210, mean this Id does or doesn't qualify in your opinion?

If this still means "this ID is a major extension", then you are 
suggesting a very low bar be set, and authors will attempt to go just 
below this bar to get TSVWG to be able to accept an ID as a WG item.

James
<with my author hat on>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 12 Nov 2009 22:21:10 +0100

> Sent: Thursday, November 12, 2009 10:13 PM
> To: PAPADIMITRIOU Dimitri; ken carlberg
> Cc: [email-masked]
> Subject: RE: [tsvwg] What's a minor vs major change to RSVP ?
> 
> <with my author hat on>
> 

It does not qualify. Takes the limit as RFC 2205, and RFC 2210 
sticking to RSVP. 
 
Thanks,
-dimitri.

---

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

>extensions but at later stage if necessary.

If I'm understanding your comments correctly, if there is 100% 
backwards compatibility ensuring zero changes to the installed base, 
this is not a major extension to any protocol.  The converse would be 
- devices that don't understand the extension aren't adversely 
affected but the presence of the extension.

Is that the essence of what you're saying?

James

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 13 Nov 2009 20:46:54 +0100

IMHO, major change to RSVP (RFC 2205) and a major change to RSVP for
IntServ (RFC 2210).
(Let's not enter in the IntServ model discussion for the time being).
 
Thanks,
-d.

________________________________

	From: ken carlberg [mailto:[email-masked]] 
	Sent: Thursday, November 12, 2009 5:08 PM
	To: PAPADIMITRIOU Dimitri
	Cc: [email-masked]
	Subject: Re: [tsvwg] What's a minor vs major change to RSVP ?

	so, from your perspective and based on the passage you cite,
does the multi-tspec draft constitute a minor or major change to RSVP?
The draft defines a single extension. 

	-ken

	

		Hi 

		Following the discussion during this TSVWG meeting about
what's a minor and a major change to RSVP, the boundary condition seems
to be: change to RFC 1633 and 2205. 

		(B) 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. In order to maintain
stable
		specifications, additional work on RSVP in TSVWG
requires Area
		Director approval. 

		Henee, I'd ask to the TSV chairs to include this
distinction as part of the charter. This would prevent any further
"confusion" on what's a minor vs major change to RSVP. 

		Thanks, 
		-dimitri.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 13 Nov 2009 14:18:15 -0600

<with my author hat on>

I respectfully disagree this is a major change to either, and am 
wondering what you consider to be a minor change to either...

James

>(Let's not enter in the IntServ model discussion for the time being).

Am I understanding that you don't want to see any IntServ discussion 
within TSVWG?

If so, which WG should the MULTI_TSPEC ID go in front of for discussion?

<with my author hat on>

James

>----------

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 13 Nov 2009 21:20:13 +0100

> Sent: Friday, November 13, 2009 2:29 AM

No. 

In essence: backward compatibility is necessary but it is not a
sufficient condition to be qualified as "minor extension" of the
protocol. All the points here above show the protocol change you bring
in with this document.

-d.

> distinction as part

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 13 Nov 2009 14:24:49 -0600

>protocol. All the points here above show the protocol change you bring

sorry this was so drawn out, but I now am clear what you are saying.

Thanks

James

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 13 Nov 2009 22:17:09 +0100

> Sent: Friday, November 13, 2009 9:18 PM

New procedures and messages/objects that were not part of the initial
specification.
 
> Am I understanding that you don't want to see any IntServ discussion 

No. I just wanted to state that the "extension" to RSVP RFC is
sufficient to open this discussion (but extending RSVP for IntServ with
new merging rules raise the question of IntServ spec udpate as well, my
initial reference to RFC 1633).

> If so, which WG should the MULTI_TSPEC ID go in front of for 

You would need to re-charter TSVWG to have this discussion. For this to
happen you would first need i) the consensus on direction for these
extensions to ensure that working group agrees on the topic(s) brought
in and ii) the actual support from a larger RSVP
development/implementation community (to ensure that those specifying
these extensions are not the only ones implementing them).  

-d.