[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IANA Considerations for RSVP
- To: Bala Rajagopalan <BRaja@tellium.com>
- Subject: Re: IANA Considerations for RSVP
- From: Dimitri.Papadimitriou@alcatel.be
- Date: Fri, 24 Jan 2003 08:48:11 +0100
- Cc: "'David Charlap'" <David.Charlap@marconi.com>, Brian Hassink <BHassink@HatterasNetworks.com>, Bob Braden <braden@ISI.EDU>, 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
- Organization: Optical Network Architecture (NTA - Antwerpen)
- References: <05707214338CD5119BFF0040A5B170D302889721@mail3.tellium.com>
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: 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
> >
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : Work: +32 3 2408491 - Home: +32 2 3434361