RE: IANA Considerations for RSVP

[Bala Rajagopalan <BRaja@tellium.com>]

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: braja@tellium.com


> -----Original Message-----
> From: David Charlap [mailto:David.Charlap@marconi.com]
> Sent: Thursday, January 23, 2003 11:15 AM
> To: Brian Hassink
> Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET;
> kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com;
> bwijnen@lucent.com
> 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
>