[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Rsvp] RE: IANA Considerations for RSVP



[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

  *> 
  *> 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: braja@tellium.com
  *> 
  *> 
  *> > -----Original Message-----
  *> > From: Dimitri.Papadimitriou@alcatel.be
  *> > [mailto:Dimitri.Papadimitriou@alcatel.be]
  *> > Sent: Friday, January 24, 2003 2:48 AM
  *> > To: Bala Rajagopalan
  *> > Cc: 'David Charlap'; Brian Hassink; 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
  *> > 
  *> > 
  *> > 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
  *> > 
  *> _______________________________________________
  *> Rsvp mailing list
  *> Rsvp@mailman.isi.edu
  *> http://mailman.isi.edu/mailman/listinfo/rsvp
  *>