Subject: RE: IANA Considerations for RSVP

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Thu, 23 Jan 2003 11:42:14 -0500

Hi David,

I responded to an earlier message (you probably haven't seen it yet), but I just want to re-iterate some points here, especially the point about not wanting to work together.

I'm not sure whether you've followed the work in CCAMP WG, but I've made the point that the ITU-T has notified and provided status as well as their "draft" documents to IETF consistently and regularly for the last few IEFT CCAMP WG meetings.

As such, your point that you gave below I take it to imply that you either (1) have not followed the recent work in CCAMP, or (2) you choose to selectively ignore the work submitted to CCAMP. 

In either case I don't think this should be blamed on the folks who's (individually) submitted the work to IETF as individuals who are full-fledged members of the IETF community...

Zhi

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 11:15 AM
To: Brian Hassink
Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: IANA Considerations for RSVP

Brian Hassink wrote:
> Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol?

There's a big difference.  MPLS and IntServ are both IETF groups.  (And 
RSVP has/had its own working group anyway).  Also, most of the key RSVP 
people were involved in the development of RSVP-TE.

This is very different from what I'm describing - where people who have 
no prior RSVP experience decide that they can start changing it without 
understing it, and without even notifying the IETF groups that did all 
of the development work.

I'mnot saying that RSVP should never be extended.  I'm saying that those 
groups that are writing extensions should be consulting with those who 
have been developing and maintaining it (in the RSVP and MPLS groups) in 
order to ensure that:
	- Their goal can't be achieved without extending the language
	- That their extension doesn't overlap a similar extension
	  from somebody else.
	- That their extension doesn't significantly change the overall
	  semantics of RSVP.
	- That their extension is sufficiently flexible so that other
	  groups can build off of it instead of re-inventing the wheel
	  with yet another incompatible extension.

Not only isn't this happening, but there appears to be no desire to see 
this happen.

-- David

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 23 Jan 2003 08:48:53 -0800

Folks,

Keep in mind also that we are talking about the application of RSVP
to switched transport networks (i.e., SDH), not to IP networks directly.
This is the scope of the ITU specification that would use these
extensions.

Cheers,

Lyndon Ong

---

From: Scott W Brim <[email-masked]>
Date: Thu, 23 Jan 2003 12:15:21 -0500

Sorry, accidentally narrowed the list.

Date: Thu, 23 Jan 2003 12:08:11 -0500
From: Scott W Brim <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

On Wed, Jan 22, 2003 09:40:12PM +0000, Bob Braden allegedly wrote:
> 3. The IANA Considerations draft should be published as an RFC,
> 	perhaps after updating.  Here are some issues that might affect
> 	this update.

All good ideas, but they still don't lead to integration.  In ATM you
find a (personal opinion) hodgepodge of overlapping capabilities in the
signaling IEs because of the lack of strict control and insistence on
coordinated engineering.  Keep the idea of a separate name space in the
back pocket and try for better.  Incrementally, perhaps have just one
more name class, "non-IETF" and insist on a statement that the group
proposing the new extension document how it interacts with existing
ones.  But, if you're going to do that, you could insist on that
documentation and not have the different categories.  Whatever you think
we can pull off.

> 		Must there be an Internet Draft? An RFC?  We have
> 		tended towards the RFC, but the result is less than
> 		satisfactory.  These extensions are typically
> 		documented in some 373- page document published (or
> 		more often hidden) by the other standards body.  The
> 		I-D/RFC that is written for registration presents only
> 		a superficial summary of the data structures to be
> 		defined, with no context of explanation,  and a
> 		reference to the real 373 page document.

There must be an RFC, even if status is informational.  documentation
must be in space that's visible to users of RSVP, and that means
publicly visible, not restricted to members of bodies who are requesting
the extensions.  

.Scott

---

From: "Mak, L (Leen)" <[email-masked]>
Date: Thu, 23 Jan 2003 18:01:15 +0100

David

You wrote:

> In other words, these groups seem to want to forcibly change 
> RSVP into a protocol that more closely resembles some other 
> protocol that they're more intimately familiar with.

My recollection of history brings me to a little paraphrasing of
your statement:

- In other words, the IETF seemed to want to forcibly change 
- transport networking into a thing that more closely resembles 
- some other network that they're more intimately familiar with.

If you agree, let's than put the pots and the kettles where they
belong and join forces on a constructive way forward. That is
in our common interest.

Leen Mak.

---

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Thu, 23 Jan 2003 12:52:17 -0500

Hi Eric,

Please see Steve's email on the history. After reading that, I hope you would change your mind about the "fait accompli" remark...

Thanks
Zhi

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 12:43 PM
To: Lin, Zhi-Wei (Zhi)
Cc: David Charlap; Bob Braden; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: IANA Considerations for RSVP

Zhi,

    Yours may be an equally unfair characterization.  In general, the reaction
in the IETF to any intended RFC submitted as a 'fait accompli' is similar to
what you are seeing here - regardless of whether it came from an individual
or an organization representative.

"Lin, Zhi-Wei (Zhi)" wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols...
>

...

---

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Thu, 23 Jan 2003 14:04:20 -0500

Hi Kireeti,

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 1:53 PM
To: Lin, Zhi-Wei (Zhi)
Cc: David Charlap; Bob Braden; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: IANA Considerations for RSVP

Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted
> by individuals. In terms of changing these protocols...

I beg to differ.  The publication request of the original RSVP-TE spec was
made *by the MPLS WG*.  The publication request of the GMPLS RSVP spec was
makde *by the CCAMP WG*.  Furthermore, the issue is not who submits the
document; it is the degree of scrutiny it gets.  *Standards Track* docs
go through a much stricter review than informational ones.

<zhi>Right. the set of ASON documents are all targeted for informational RFC, though and not standards track. It was recommended that such document should be submitted to assist IANA with codepoint assignment, and that's what was done...

In terms of degree of scrutiny, please see Steve's email on the history of trying to get feedback...this was really "like pulling teeth"...</zhi>

> The GMPLS RSVP-TE, which is done in IETF, makes major modifications to
> RFC3209 and RFC2205 version of RSVP. The rest of the changes been
> requested are three new objects, new error codes to support these
> objects. This can hardly be characterized as forcibly changing RSVP or
> major change in direction...

Do you consider deprecating ResvErr and ResvTear not "forcibly changing
RSVP or major change in direction"?

<zhi>I don't understand...where do you see that these are deprecated??? What is said in my document is that these messages we don't create because all teardowns are explicit. But when these are received, then we will take appropriate actions (see document).

Do you consider that if we don't transmit a message then this is in violation of the protocol? We're transmitting all messages in accordance with RFC2205/3209/GMPLS-RSVP-TE...There are approximately 20 message types, but GMPLS RSVP-TE only use a sub-set that's important to its function (e.g., DREQ and DREP are not mandatory for GMPLS RSVP-TE)...
</zhi>

Kireeti.

---

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Thu, 23 Jan 2003 15:28:12 -0500

Hi Kireeti,

I didn't mean to imply what you said. I apologize if I offended you. Just that the site was not very well publicized by the IESG. I only became aware of it after someone pointed me to it. 

Zhi

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 3:22 PM
To: Lin, Zhi-Wei (Zhi)
Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked]
Subject: RE: IANA Considerations for RSVP

Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Please visit the IESG page, go to I-D tracker, and search under the
> document...

I just did.  Oh, well.

> I guess some IETF WG chairs don't pay attention to this...

And you're implying?  My imcompetence, or the fact that this is not
the product of a WG?

But you're right, this has been approved by the IETF.  More accurately,
as the email to IETF announce says, by the IESG.

Kireeti.

---

From: John Drake <[email-masked]>
Date: Thu, 23 Jan 2003 17:12:46 -0800

Scott,

You saved me some typing.

John

> From: Scott W Brim [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 4:27 PM
> To: Stephen Trowbridge
> Cc: John Drake; David Charlap; Brian Hassink; Bob Braden; 
> [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> On Thu, Jan 23, 2003 04:24:31PM -0700, Stephen Trowbridge 
> allegedly wrote:
> > John,
> > Hmmm... a bit IETF centric.
> > Because some portion of a problem space touches or uses an 
> IETF protocol,
> > then clearly the entire problem must belong to IETF.
> 
> The entire problem of signing off on extensions to the protocol does
> belong to the IETF, if you want them to be used outside of some local
> network.  That's for architectural consistency.
> 
> > Consider that the ASON architecture encompasses transport 
> networks where
> > what we call the transport plane (IETF calls the data plane) is not
> > necessarily IP. What if the addresses are NSAP addresses 
> instead of IP
> > addresses? What if some or all of the signaling links employ PNNI
> > as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still
> > all belong to IETF? These are problems that cannot be solved without
> > good cooperation between the standards organizations that 
> are involved.
> 
> The IETF is responsible for defining the mechanisms by which those
> non-IP addresses can be carried in the IP-based protocol.
> 
> > In terms of the existance of a communication channel and 
> procedures for
> > collaborating between IETF and ITU-T, this exists but 
> perhaps, in spite
> > of receiving these liaisons, you have not taken the trouble 
> to become
> > familiar with it. Identical text describing the 
> collaboration process is
> > published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We 
> are following
> > the documented process, and this suggests a different 
> answer than your
> > emails to the question of which side of this communication 
> channel is
> > not holding up their end.
> 
> I agree the communication channels could be used better.  I also think
> that the best way to communicate is probably NOT those channels, but
> rather to bring in parallel technical contributions in each group, to
> make sure they are in sync.  Take the ideas through the 
> procedures that
> participants actually care about.
> 
> swb
>

---

From: Jeff Parker <[email-masked]>
Date: Fri, 24 Jan 2003 11:24:11 -0500

> Going forward, I hope the IETF makes it mandatory
> to have outside work examined in the relevant WGs with
> the same seriousness as regular WG items (or assign
> evaluation teams, like design teams). 
>
> Bala Rajagopalan
 
Given that much of the work done at the IETF is
done by volunteers, this bar may not be as high
as it seems.  I see Last Calls on WG items in a
number of groups that elicit little or no comment.  

It is certainly worth the effort to try to make
cooperation between IETF and other bodies easier.
But unfunded mandates are difficult to staff.  

- jeff parker

---

From: Bob Braden <[email-masked]>
Date: Sun, 26 Jan 2003 20:10:38 -0800 (PST)

*> David
  *> 
  *> You wrote:
  *> 
  *> > In other words, these groups seem to want to forcibly change 
  *> > RSVP into a protocol that more closely resembles some other 
  *> > protocol that they're more intimately familiar with.
  *> 
  *> My recollection of history brings me to a little paraphrasing of
  *> your statement:
  *> 
  *> - In other words, the IETF seemed to want to forcibly change 
  *> - transport networking into a thing that more closely resembles 

Sorry, I am unfamiliar with the term "transport networking".  Could you
explain it please?

Thanks,

Bob Braden

  *> - some other network that they're more intimately familiar with.
  *> 
  *> If you agree, let's than put the pots and the kettles where they
  *> belong and join forces on a constructive way forward. That is
  *> in our common interest.
  *> 
  *> Leen Mak.
  *> 
  *>  
  *> _______________________________________________
  *> Rsvp mailing list
  *> [email-masked]
  *> http://mailman.isi.edu/mailman/listinfo/rsvp
  *>

---

From: Bob Braden <[email-masked]>
Date: Sun, 26 Jan 2003 20:23:00 -0800 (PST)

David,

I would like to mention that I thoroughly support all you have been
saying in this thread -- and you have been saying it forcefully and
well.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Sun, 26 Jan 2003 20:39:07 -0800 (PST)

Friends,

In trying to sort out how we should have handled RSVP_TE and all its
offspring, it is instructive to read RFC 2814 that describes the
Subnet Bandwidth Manager (SBM).  Like RSVP-TE and its offspring,
the SBM was an RSVP-like protocol for signaling at the link layer.
It is carefully documented as a distinct protocol, alhtough in
fact there are RSVP extensions for the SBM.  It leaves RSVP as
a network- (i.e., Internet-)layer protocol, as it was originally
designed.

I believe using the SBM approach for RSVP-TE would have avoided some of
the problems we are seeing today.  To imply, as I often see done, that
RSVP-TE is "just RSVP with a few extensions" was and is dishonest.  Its
semantics are fundamentally different in important ways, even if the
syntax is the same.  There is more to protocols than bit and byte
formats.

Do we need to have this discussion of 3 large mailing lists?

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Sun, 26 Jan 2003 20:45:04 -0800 (PST)

*> 
  *> Going forward, I hope the IETF makes it mandatory
  *> to have outside work examined in the relevant WGs with
  *> the same seriousness as regular WG items (or assign
  *> evaluation teams, like design teams). This would bring
  *> overall sanity and be beneficial for all groups.
  *> 

This is one good choice -- the other is to clearly fence off the
non-IETF extensions with a surgeon general's warning.

Bob Braden

  *> regards,
  *> 
  *> 
  *> Bala Rajagopalan
  *> Tellium, Inc.
  *> 2 Crescent Pl.
  *> Ocean Port, NJ 07757
  *> USA
  *> Ph: +1-732-923-4237
  *> Email: [email-masked]
  *> 
  *> 
  *> > -----Original Message-----
  *> > From: [email-masked]
  *> > [mailto:[email-masked]]
  *> > Sent: Friday, January 24, 2003 2:48 AM
  *> > To: Bala Rajagopalan
  *> > Cc: 'David Charlap'; Brian Hassink; Bob Braden; [email-masked];
  *> > [email-masked]; [email-masked]; [email-masked]; [email-masked];
  *> > [email-masked]; [email-masked]; [email-masked]
  *> > Subject: Re: IANA Considerations for RSVP
  *> > 
  *> > 
  *> > bala,
  *> > 
  *> > your assertion "none of the IETF WGs (specifically, CCAMP)
  *> > have shown any interest in discussing the (informational)
  *> > drafts about ASON or OIF at any length." is not true
  *> > if you were really participating to the ccamp wg meeting
  *> > in yokohama you would have heard that the consensus was
  *> > (as requested by the chair) to send a ason functional 
  *> > spec to the ccamp wg in order for the latter to define
  *> > the needed extensions - the proposal was to achieve 
  *> > a first cut of these extensions in november '02 but
  *> > nothing happened everything goes to "informational"
  *> > 
  *> > the reason why suddenly things gets tunneled until
  *> > reaching the current situation are still unclear for
  *> > me (one of the explanation i have is the clear rambo
  *> > competition played by the oif in backing up these 
  *> > extensions instead of letting the corresponding 
  *> > responsibility to the appropriate body i.e. the ietf)
  *> > 
  *> > thanks,
  *> > - dimitri.
  *> > 
  *> > Bala Rajagopalan wrote:
  *> > > 
  *> > > Hello,
  *> > > 
  *> > > First, the IETF has been instrumental in putting
  *> > > IP/MPLS protoocols for use in the optical control plane.
  *> > > You can't now complain that RSVP is being indiscriminately
  *> > > used for purposes other than intended. To quote
  *> > > a cliche, you can't have the cake intact and modify it
  *> > > too.
  *> > > 
  *> > > Second, none of the IETF WGs (specifically, CCAMP)
  *> > > have shown any interest in discussing the (informational)
  *> > > drafts about ASON or OIF at any length. Serious
  *> > > consideration by the WGs should lead to an examination
  *> > > of the solutions proposed and a liaison to ITU-T or OIF
  *> > > or whichever body about tweaks that are out
  *> > > of whack with the protocol architecture.
  *> > > Instead, what we usually end up with are WG
  *> > > Rambos who simply shoot down the entire model of
  *> > > ITU-T or OIF and move on.
  *> > > 
  *> > > Finally, it's not so easy to steer away from RSVP altogether
  *> > > (even if it makes sense to do so)
  *> > > due to the installed code base of dominant vendors.
  *> > > 
  *> > > In summary, there is a lot of pressure to use RSVP outside
  *> > > of IETF, and the IETF should systematically review the
  *> > > outside work to ensure technical sanity.
  *> > > 
  *> > > Regards,
  *> > > 
  *> > > Bala Rajagopalan
  *> > > Tellium, Inc.
  *> > > 2 Crescent Pl.
  *> > > Ocean Port, NJ 07757
  *> > > USA
  *> > > Ph: +1-732-923-4237
  *> > > Email: [email-masked]
  *> > > 
  *> > > > -----Original Message-----
  *> > > > From: David Charlap [mailto:[email-masked]]
  *> > > > Sent: Thursday, January 23, 2003 11:15 AM
  *> > > > To: Brian Hassink
  *> > > > Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
  *> > > > [email-masked]; [email-masked]; [email-masked]; 
  *> > [email-masked];
  *> > > > [email-masked]
  *> > > > Subject: Re: IANA Considerations for RSVP
  *> > > >
  *> > > >
  *> > > > Brian Hassink wrote:
  *> > > > > Didn't the IETF set the precedent by extending RSVP from an
  *> > > > IntServ protocol to an MPLS protocol?
  *> > > >
  *> > > > There's a big difference.  MPLS and IntServ are both IETF
  *> > > > groups.  (And
  *> > > > RSVP has/had its own working group anyway).  Also, most of
  *> > > > the key RSVP
  *> > > > people were involved in the development of RSVP-TE.
  *> > > >
  *> > > > This is very different from what I'm describing - where
  *> > > > people who have
  *> > > > no prior RSVP experience decide that they can start changing
  *> > > > it without
  *> > > > understing it, and without even notifying the IETF groups
  *> > > > that did all
  *> > > > of the development work.
  *> > > >
  *> > > > I'mnot saying that RSVP should never be extended.  I'm saying
  *> > > > that those
  *> > > > groups that are writing extensions should be consulting with
  *> > > > those who
  *> > > > have been developing and maintaining it (in the RSVP and MPLS
  *> > > > groups) in
  *> > > > order to ensure that:
  *> > > >       - Their goal can't be achieved without extending 
  *> > the language
  *> > > >       - That their extension doesn't overlap a similar extension
  *> > > >         from somebody else.
  *> > > >       - That their extension doesn't significantly change 
  *> > the overall
  *> > > >         semantics of RSVP.
  *> > > >       - That their extension is sufficiently flexible so 
  *> > that other
  *> > > >         groups can build off of it instead of 
  *> > re-inventing the wheel
  *> > > >         with yet another incompatible extension.
  *> > > >
  *> > > > Not only isn't this happening, but there appears to be no
  *> > > > desire to see
  *> > > > this happen.
  *> > > >
  *> > > > -- David
  *> > > >
  *> > 
  *> > -- 
  *> > Papadimitriou Dimitri 
  *> > E-mail : [email-masked] 
  *> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
  *> > E-mail : [email-masked]
  *> > Public : http://psg.com/~dpapadimitriou/
  *> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
  *> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
  *> > 
  *> _______________________________________________
  *> Rsvp mailing list
  *> [email-masked]
  *> http://mailman.isi.edu/mailman/listinfo/rsvp
  *>

---

From: Bob Braden <[email-masked]>
Date: Sun, 26 Jan 2003 20:20:51 -0800 (PST)

*> 
  *> David,
  *> 
  *>     The intent to build a new protocol, rather than bastardize an existing
  *> one has gotten a very large number of people burned in recent times.

Could you cite some specific examples of this?  The one that comes to
mind is LDP, I suppose.  I am not sure anyone was burned by LDP, were
they?

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Sun, 26 Jan 2003 20:17:26 -0800 (PST)

*> 
  *> On Thu, Jan 23, 2003 11:06:53AM -0500, Brian Hassink allegedly wrote:
  *> > Didn't the IETF set the precedent by extending RSVP from an IntServ
  *> > protocol to an MPLS protocol?
  *> 
  *> Check the documentation.  RSVP is not an intserv protocol.  It's
  *> (potentially) used by intserv.  It's also used for other things.
  *> _______________________________________________

Scott,

Weeellll, RSVP *was* designed as the signaling protocol for int-serv.
Since we believe that generality and extensibility are Good Things,
we made it general and extensible.  (Again, perhaps a mistake, in
retrospect ... ;-( )

Bob

---

From: Bob Braden <[email-masked]>
Date: Mon, 27 Jan 2003 22:13:47 GMT

*> 
  *> 
  *> Friends,
  *> 
  *> In trying to sort out how we should have handled RSVP_TE and all its
  *> offspring, it is instructive to read RFC 2814 that describes the
  *> Subnet Bandwidth Manager (SBM).  Like RSVP-TE and its offspring,

I apologize for a misstatement here; I should not have singled out
RSVP-TE for abuse.  In fact, there are at least two or three distinct
flavors of RSVP offspring: RSVP-TE for MPLS setup, the OIF folks who
have an RSVP-like protocol for link-layer signaling at the UNI,
and maybe the ATM folks.  (I assume the GMPLS folks fall into the
RSVP-TE camp.) The same comment about SBM applies equally to all these
"illegitimate offspring" of RSVP.

(They are each fine upstanding protocols in their own right, no
doubt; it is only their parentage that is shady.)

Bob Braden

  *> the SBM was an RSVP-like protocol for signaling at the link layer.
  *> It is carefully documented as a distinct protocol, alhtough in
  *> fact there are RSVP extensions for the SBM.  It leaves RSVP as
  *> a network- (i.e., Internet-)layer protocol, as it was originally
  *> designed.
  *> 
  *> I believe using the SBM approach for RSVP-TE would have avoided some of
  *> the problems we are seeing today.  To imply, as I often see done, that
  *> RSVP-TE is "just RSVP with a few extensions" was and is dishonest.  Its
  *> semantics are fundamentally different in important ways, even if the
  *> syntax is the same.  There is more to protocols than bit and byte
  *> formats.
  *> 
  *> Do we need to have this discussion of 3 large mailing lists?
  *> 
  *> Bob Braden
  *> _______________________________________________
  *> Rsvp mailing list
  *> [email-masked]
  *> http://mailman.isi.edu/mailman/listinfo/rsvp
  *>