Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 12:58:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301272004.PAA16128@workhorse.fictitious.org> To: Bala Rajagopalan cc: "'Dimitri.Papadimitriou@alcatel.be'" , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: IANA Considerations for RSVP Date: Mon, 27 Jan 2003 15:04:11 -0500 From: Curtis Villamizar spamassassin -r d ajagopalan writes: > Dimitri: > > I don't recall the particular Yokohoma consensus > you mention, although what you say could very well > have happened. All I do remember is the total lack > of interest in the audience about most of the drafts > discussed. > > My gripe is basically about the lack of a process in > the IETF to rigorously and constructively evaluate > on-going work outside. The liaisons > obviously haven't worked very well, and the efforts > by various people to bring in contributions on OIF > and ASON work have been met with cynicism. This is > the reason why there's a scramble at the last minute > to "right" things. > > 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. > > regards, > > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Pl. > Ocean Port, NJ 07757 > USA > Ph: +1-732-923-4237 > Email: braja@tellium.com Any organization or representative may sumbit an internet draft and it may be given consideration by the WG. It carries no more weight than any other individual WG submission. If the WG is not interested, that is the end of it. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 12:34:51 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D30288973A@mail3.tellium.com> From: Bala Rajagopalan To: "'curtis@fictitious.org'" Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: IANA Considerations for RSVP Date: Mon, 27 Jan 2003 15:29:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > 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. > > > > Any organization or representative may sumbit an internet draft and it > may be given consideration by the WG. It carries no more weight than > any other individual WG submission. > > If the WG is not interested, that is the end of it. > > Curtis > This is precisely the problem. The above mode of operation is fine when considering work to be done within an IETF WG. But it results in the sort of grumbling we heard recently when external orgs do independent work. There needs to be a process to look at external work more rigorously (or, ignore "uninteresting" work completely and not worry about IETF protocol changes elsewhere). Bala Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 07:33:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301270423.h0R4N0s28487@boreas.isi.edu> Date: Sun, 26 Jan 2003 20:23:00 -0800 (PST) From: Bob Braden To: David.Charlap@marconi.com Subject: Re: [Rsvp] Re: IANA Considerations for RSVP Cc: 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 [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 07:33:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301270417.h0R4HQs26211@boreas.isi.edu> Date: Sun, 26 Jan 2003 20:17:26 -0800 (PST) From: Bob Braden To: sbrim@cisco.com Subject: Re: [Rsvp] Re: IANA Considerations for RSVP Cc: David.Charlap@marconi.com, 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 [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] *> *> 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 07:33:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301270410.h0R4AcU23818@boreas.isi.edu> Date: Sun, 26 Jan 2003 20:10:38 -0800 (PST) From: Bob Braden To: David.Charlap@marconi.com, braden@ISI.EDU, lmak@lucent.com Subject: Re: [Rsvp] RE: IANA Considerations for RSVP Cc: 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 [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] *> 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 *> Rsvp@mailman.isi.edu *> http://mailman.isi.edu/mailman/listinfo/rsvp *> Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 07:32:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301270445.h0R4j4Q08602@boreas.isi.edu> Date: Sun, 26 Jan 2003 20:45:04 -0800 (PST) From: Bob Braden To: Dimitri.Papadimitriou@alcatel.be, BRaja@tellium.com Subject: Re: [Rsvp] RE: IANA Considerations for RSVP Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET [ 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 -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 *> Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 07:32:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301270439.h0R4d7Y06027@boreas.isi.edu> Date: Sun, 26 Jan 2003 20:39:07 -0800 (PST) From: Bob Braden To: David.Charlap@marconi.com, braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 07:32:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301270420.h0R4Kpo27844@boreas.isi.edu> Date: Sun, 26 Jan 2003 20:20:51 -0800 (PST) From: Bob Braden To: David.Charlap@marconi.com, GraIyMag@GraIyMage.com Subject: Re: [Rsvp] Re: IANA Considerations for RSVP Cc: 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 [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] *> *> 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Jan 2003 07:32:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301270414.h0R4EtU25153@boreas.isi.edu> Date: Sun, 26 Jan 2003 20:14:55 -0800 (PST) From: Bob Braden To: braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, jplang@ieee.org Subject: Re: [Rsvp] [Fwd: 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] *> *> Last time I checked, the IETF didn't change the protocols, *> individuals did through contributions. The extensions requested for *> Call/Connection control were submitted by an individual. The fact the *> ITU weighed in requesting approval of the changes is a separate issue. *> *> So if this was an individual contribution, then it wouldn't be tagged *> "ITU-T_SPIFFY_SESSION"? This statement by Zhi leaves my head spinning. One of us has a very confused notion of reality. Bob Braden Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 25 Jan 2003 03:09:45 -0800 Message-ID: <3E326DE4.1B467B60@alcatel.be> Date: Sat, 25 Jan 2003 11:58:44 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Document Action: LDP and RSVP Extensions for Optical UNI Signalingto Informational (fwd) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii kireeti, all, would it be possible to ask to the author to add a backward compatibility section in this document and this with respect to the gmpls rsvp-te proposed standard and related thanks, - dimitri. Kireeti Kompella wrote: > > FYI > > ---------- Forwarded message ---------- > Date: Thu, 23 Jan 2003 16:23:42 -0500 > From: The IESG > To: IETF-Announce: ; > Cc: RFC Editor , Internet Architecture Board > Subject: Document Action: LDP and RSVP Extensions for Optical UNI > Signaling to Informational > > The IESG has approved the Internet-Draft 'LDP and RSVP Extensions for > Optical UNI Signaling' as > an Informational RFC. This has been reviewed in the IETF but is not the > product of an IETF Working Group. > > The IESG contact person is Scott Bradner. -- 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 24 Jan 2003 08:47:28 -0800 Message-ID: <3E316DE3.2DFBA173@lucent.com> Date: Fri, 24 Jan 2003 09:46:27 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Bala Rajagopalan CC: "'Dimitri.Papadimitriou@alcatel.be'" , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: IANA Considerations for RSVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bala, Excellent suggestion. Steve Bala Rajagopalan wrote: > > Dimitri: > > I don't recall the particular Yokohoma consensus > you mention, although what you say could very well > have happened. All I do remember is the total lack > of interest in the audience about most of the drafts > discussed. > > My gripe is basically about the lack of a process in > the IETF to rigorously and constructively evaluate > on-going work outside. The liaisons > obviously haven't worked very well, and the efforts > by various people to bring in contributions on OIF > and ASON work have been met with cynicism. This is > the reason why there's a scramble at the last minute > to "right" things. > > 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. > > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 24 Jan 2003 08:27:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Jeff Parker To: "'Bala Rajagopalan'" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: IANA Considerations for RSVP Date: Fri, 24 Jan 2003 11:24:11 -0500 [ 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 -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). > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 24 Jan 2003 08:08:47 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com> From: Bala Rajagopalan To: "'Dimitri.Papadimitriou@alcatel.be'" , Bala Rajagopalan Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: IANA Considerations for RSVP Date: Fri, 24 Jan 2003 10:47:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri: I don't recall the particular Yokohoma consensus you mention, although what you say could very well have happened. All I do remember is the total lack of interest in the audience about most of the drafts discussed. My gripe is basically about the lack of a process in the IETF to rigorously and constructively evaluate on-going work outside. The liaisons obviously haven't worked very well, and the efforts by various people to bring in contributions on OIF and ASON work have been met with cynicism. This is the reason why there's a scramble at the last minute to "right" things. 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. 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 23:51:21 -0800 Message-ID: <3E30EFBB.6A3A90AF@alcatel.be> Date: Fri, 24 Jan 2003 08:48:11 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) MIME-Version: 1.0 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 17:13:58 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97218C@nimbus> From: John Drake To: 'Scott W Brim' , Stephen Trowbridge 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 Date: Thu, 23 Jan 2003 17:12:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Scott, You saved me some typing. John > -----Original Message----- > From: Scott W Brim [mailto:sbrim@cisco.com] > Sent: Thursday, January 23, 2003 4:27 PM > To: Stephen Trowbridge > Cc: John Drake; 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 > > > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 16:28:01 -0800 Date: Thu, 23 Jan 2003 19:26:55 -0500 From: Scott W Brim To: Stephen Trowbridge Cc: John Drake , 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 Message-ID: <20030124002654.GG1856@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , Stephen Trowbridge , John Drake , 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 16:25:35 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D302889721@mail3.tellium.com> From: Bala Rajagopalan To: 'David Charlap' , 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 Date: Thu, 23 Jan 2003 12:03:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 15:51:08 -0800 Message-ID: <3E30298A.881E59C3@GraIyMage.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 23 Jan 2003 12:42:34 -0500 From: Eric Gray To: "Lin, Zhi-Wei (Zhi)" CC: David Charlap , 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 [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] 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... > ... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 15:49:57 -0800 Message-ID: <3E30260A.82698500@GraIyMage.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 23 Jan 2003 12:27:38 -0500 From: Eric Gray To: David Charlap 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 [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] 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. I can't say as I blame external organizations - who, in almost every case, have mostly only seen the flames from prior efforts coloring the sky - from opting to modify an existing protocol. We shouldn't chastise people for making what they feel are the best choices based on the evidence in front of them. We should instead try to determine what they are missing, or otherwise help them to modify those choices. :-) -- Eric Gray David Charlap wrote: > Bob Braden wrote: > > > > There is a growing unease about IANA assignments of RSVP parameters -- > > object numbers, CTypes, message types, and error numbers -- for new > > uses of RSVP. Many of these IANA requests, but not all, originate > > outside the IETF in other standards bodies. Many of the people from > > outside the IETF were not part of the RSVP working group and so did not > > absorb the technical rationale behind RSVP; in fact, they are sometimes > > barely clued into IETF procedures at all. > > I've noticed the same thing. It seems that many non-IETF groups want to > use RSVP, and all believe that they must create extensions to the > protocol for their features, often without first bothering to check if > there are already obects defined by IETF standards that already serve > their purposes. And even in those cases where new objects may be > required, the proposed objects are often defined as having semantics > that differ greatly from the way RSVP usually operates. > > 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. > > Personally, I don't like this. These groups should step back and decide > if RSVP is really what they need. If they require a different protocol, > then they should use a different protocol - they should not glom onto > RSVP just because it's popular in MPLS and then try to change it into > what they really want. This is especially true in those situations > where their proposed changes would produce a fundamentally incompatible > protocol. > > Unfortunately, I don't know what can be done about this. These groups > seem hell-bent on hacking up RSVP without first learning it's design > philosophy. If they don't get assignments from IANA, they'll probably > just make their own assignments without any coordinating facility, and > we'll wind up with several mutually incompatible protocols that all want > to call themselves "RSVP". > > -- David Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 15:46:39 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> Thread-Topic: IANA Considerations for RSVP Thread-Index: AcLC+OcbwxgKzZ6bT1yvaa9ntdugvgAAEKRg Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 11:06:53 -0500 From: "Brian Hassink" To: "David Charlap" , "Bob Braden" Cc: , , , , , , , [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Didn't the IETF set the precedent by extending RSVP from an IntServ = protocol to an MPLS protocol? CR-LDP exists as a purpose built alternative, but vendor politics = resulted in the above precedent. Just my opinion. Cheers, Brian -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Thursday, January 23, 2003 10:56 AM To: Bob Braden Cc: 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 Bob Braden wrote: >=20 > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. Many of these IANA requests, but not all, originate > outside the IETF in other standards bodies. Many of the people from > outside the IETF were not part of the RSVP working group and so did = not > absorb the technical rationale behind RSVP; in fact, they are = sometimes > barely clued into IETF procedures at all. I've noticed the same thing. It seems that many non-IETF groups want to = use RSVP, and all believe that they must create extensions to the=20 protocol for their features, often without first bothering to check if=20 there are already obects defined by IETF standards that already serve=20 their purposes. And even in those cases where new objects may be=20 required, the proposed objects are often defined as having semantics=20 that differ greatly from the way RSVP usually operates. 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=20 more intimately familiar with. Personally, I don't like this. These groups should step back and decide = if RSVP is really what they need. If they require a different protocol, = then they should use a different protocol - they should not glom onto=20 RSVP just because it's popular in MPLS and then try to change it into=20 what they really want. This is especially true in those situations=20 where their proposed changes would produce a fundamentally incompatible=20 protocol. Unfortunately, I don't know what can be done about this. These groups=20 seem hell-bent on hacking up RSVP without first learning it's design=20 philosophy. If they don't get assignments from IANA, they'll probably=20 just make their own assignments without any coordinating facility, and=20 we'll wind up with several mutually incompatible protocols that all want = to call themselves "RSVP". -- David Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 15:26:19 -0800 Message-ID: <3E3079AF.3010ED7C@lucent.com> Date: Thu, 23 Jan 2003 16:24:31 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. 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. 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. Steve John Drake wrote: > > Stephen, > > I appreciate all the work you've done keep the IETF informed about what the > ITU is doing. All I can say is that it doesn't seem to have worked. Rather > than continuing to give us status reports on what the ITU is doing, I think > it would make more sense to do the work in the appropriate IETF working > groups. > > That was what I thought was the intent of the Feb 19th Liason: "We wish that > as we continue our review of these protocols you will be able to provide us > with recommendations on how to close these and future issues." However, a > channel of communication has not been established: how should > recommendations and issues be communicated? Who makes these, and who > communicates them? How does a two-way (or n-way) dialog take place? > > If, on the other hand, these documents were brought into an IETF WG, the > procedures and channels of communication exist and are well-known. > > Thanks, > > John > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Thursday, January 23, 2003 9:21 AM > To: David Charlap > Cc: 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 > > David, > To read these emails, it sounds as though you think that the people who > are doing this are brand new to the technology and never even considered > working with IETF to try to solve the problem. Perhaps you haven't followed > the ccamp work so closely, but here is some history: > - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison > statement > regarding our new documents with requirements and architecture for > switched (not necessarily IP) transport networks. This included a > protocol- > neutral model for call and connection management (signaling). In copies > of the ITU-T documents were made available to non-ITU-T members via an > ftp site. The liaison was placed on the IESG web site and was presented > in the ccamp meeting in Salt Lake City in December. At that same meeting, > Maarten Vissers gave a technical presentation in the sub-IP area meeting > regarding the ITU-T work in this area. > - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding > the gaps that had been identified between the ITU-T requirements (sent > earlier) and what seemed to be implemented by the GMPLS protocols. > Specifically, > 1. Call & Connection separation, e.g., a call provides the service > relationship, which may support connection operations as part of a > call. > 2. Additional error codes/values, for example, for connection rejection > (invalid connection ID). > 3. Restart mechanisms: Depending on the introduction by the ITU of > additional > control plane resiliency requirements, enhancements of the protocol > (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. > 4. Protocol enhancements in CR-LDP for support of crankback capability > from > intermediate nodes. > This liaison was presented in the Minneapolis IETF meeting during the > ccamp > working group and posted on the IESG web site. The liaison requested > assistance in closing these gaps and invited input from IETF on our work > in ITU-T. > - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, > contributions > were considered to close these gaps, resulting in text for draft > Recommendations > G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again, > we sent a liaison (dated May 10, 2002) to ask for comments on our draft > Recommendations (made available on the ftp site), to request alignment, > and > to ask for IANA code point assignments. To quote from that liaison: > "Please consider including the proposed solutions provided in G.7713.2 and > G.7713.3 > to update the existing GMPLS signaling work in support of ASON requirements. > We hope that you can help expedite the assignment of appropriate additional > error codes/values by IANA. These are needed for both RSVP-TE and CR-LDP." > This liaison was presented at the Yokohama IETF ccamp meeting. > > To refer to one point raised earlier in the thread, there are other cases > where IANA has assigned codepoints for work outside of IETF, including > other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last > May, with no response. > - Some final work was done on our drafts at a Rapporteur meeting in October, > with one result being another liaison (dated October 11, 2002) making > another plea for comments and help getting the codepoints assigned. This > liaison was presented at the Atlanta IETF ccamp meeting, and still no > response or IANA action. > > To hear now that someone thinks that the ASON work in ITU-T is some kind > of secret end-run around IETF, and not involved with or related to the > work being done internally in IETF is absurd. At every stage of the work, > IETF was kept informed of the work and invited to participate. At the > invitation for help to address the additional ITU-T requirements, there > was no response. As ITU-T progressed this work and invited further comments > and alignment of the base GMPLS protocols, again no response. And to the > final pleas for comments and codepoint assignments, no response. > > I contrast this with our interaction with the ATM forum on the same topic. > Certain operators in ITU-T are interested in using the PNNI protocol for > this application (rather than rsvp-te or cr-ldp). The ATM forum has > responded with a formal liaison into the current ITU-T Study Group 15 > meeting where they have given us a diffmarked copy with extremely > helpful and constructive suggestions about how to align our G.7713.1 > document with their work. > > After some private communication with the Area directors, we received some > advice that one tool that might be used to finally get the IANA codepoint > assignment complete would be to publish what we were doing in ITU-T as > informational RFCs. This is the stage we are at today, and given the > history I describe above, I do not think anybody can say that we are > at this point because any of us did not do everything possible to > do this work (a) in IETF, with the initial communication of requirements; > or (b) in cooperation between ITU-T and IETF, once this work had > progressed in ITU-T. > > But this is all water under the bridge. We are at the point of trying > to get some codepoints assigned for ITU-T documents we are trying to > complete. Nobody should say "no" at this point because they think we > didn't try to work this IN or WITH IETF first. It should be clear to > all that this is not the case. > Regards, > Steve Trowbridge > (vice-chairman, ITU-T Study Group 15) > > David Charlap wrote: > > > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 15:23:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200301222140.VAA00937@gra.isi.edu> From: Bob Braden Date: Wed, 22 Jan 2003 21:40:12 GMT To: rsvp@ISI.EDU Subject: IANA Considerations for RSVP Cc: ccamp@ops.ietf.org, mpls@uu.net, kireeti@juniper.net, braden@ISI.EDU, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com [ 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] There is a growing unease about IANA assignments of RSVP parameters -- object numbers, CTypes, message types, and error numbers -- for new uses of RSVP. Many of these IANA requests, but not all, originate outside the IETF in other standards bodies. Many of the people from outside the IETF were not part of the RSVP working group and so did not absorb the technical rationale behind RSVP; in fact, they are sometimes barely clued into IETF procedures at all. As a sample, here is a part of a recent message from Kireeti Kompella, co-chair of the CCAMP working group: "The problem I am trying to address is that folks are changing the RSVP spec with *Informational* documents that bypass much of the checks we have. For example, the "GMPLS RSVP-TE for ASON" draft-lin-ccamp-gmpls-ason-rsvpte-04.txt defines new objects for the purpose of "call and connection separation". I don't see any reason for such separation; even in the ITU (where this comes from), there is not a clear consensus that this is needed. However, this document breezed through the IETF "process". Furthermore, it is an *Informational* document. If this really was useful, and someone were to extend this, their document would have to be Informational by normative reference transitivity. The worst part of this is that the base protocols (RSVP, RSVP-TE and RSVP-TE for GMPLS) were IETF protocols -- and then this piece has been usurped by the ITU (where the standards track documents will be defined). What I would like to see is the bulk of each space (messages, objects, class types, etc) being Standards Action, with some space for FCFS and Private Use." This raises a bunch of technical and procedural questions; I will address some of the latter below. Several points should be made. 1. I volunteered several years ago to serve as the "designated expert" for RSVP registrations (RFC 2434), so every RSVP reservation request is referred to me. (Given the amount of recent aggrevation, this may not have been too wise a move for me.) 2. Just before the RSVP WG went dormant, its cochairs put together an IANA Considerations document and published it as an I-D. I believe that it went through a formal WG last call; at least, the WG was given an opporunity to comment on, or object to, it. It did not become an RFC, but it is available on the RSVP web site. (I recently moved it to a more prominent spot in www.isi.edu/rsvp/pub.html). As the designated expert, I follow the rules in that draft. 3. The IANA Considerations draft should be published as an RFC, perhaps after updating. Here are some issues that might affect this update. (A) How to handle requests for RSVP assignments for extensions developed outside IETF? Here is my suggestion: For all assignments of numbers for extensions defined in non-IETF standards bodies, the IANA should use assignment names (e.g., object names) that are prefixed with the name of the responsible standards body. For example, the "SPIFFY_SESSION" object would become "ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION", etc., object. (B) What policies should be imposed? The document currently divides the assignment space into two subspaces, for "IETF Consensus" and "FCFS". RFC 2434 lists various other possibilities; do we need any? Precisely what do we mean by IETF consensus? Does this require a standards-track document? (We thought it did.) We assumed that non-IETF requests would necessarily go to FCFS, but is it really FCFS + expert opinion? In other words, how much oversight should we try to exert for non-IETF RSVP extensions? I have seen some highly questionable extensions. They tend to be micro-engineering, with no sense of a larger design. (C) What are the appropriate documentation requirements? 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. Bob Braden Former co-chair of the RSVP WG Current designated expert for RSVP assignments by IANA ----- End Included Message ----- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 13:46:23 -0800 Date: Thu, 23 Jan 2003 13:44:14 -0800 (PST) From: Kireeti Kompella To: Subject: Document Action: LDP and RSVP Extensions for Optical UNI Signaling to Informational (fwd) Message-ID: <20030123134319.C85260-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII FYI ---------- Forwarded message ---------- Date: Thu, 23 Jan 2003 16:23:42 -0500 From: The IESG To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board Subject: Document Action: LDP and RSVP Extensions for Optical UNI Signaling to Informational The IESG has approved the Internet-Draft 'LDP and RSVP Extensions for Optical UNI Signaling' as an Informational RFC. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Scott Bradner. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 12:29:03 -0800 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: Kireeti Kompella , "Lin, Zhi-Wei (Zhi)" Cc: Bob Braden , ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 15:28:12 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:kireeti@juniper.net] Sent: Thursday, January 23, 2003 3:22 PM To: Lin, Zhi-Wei (Zhi) Cc: Bob Braden; ccamp@ops.ietf.org; mpls@UU.NET; iana@ISI.EDU 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 12:22:55 -0800 Date: Thu, 23 Jan 2003 12:22:08 -0800 (PST) From: Kireeti Kompella To: "Lin, Zhi-Wei (Zhi)" cc: Bob Braden , , , Subject: RE: IANA Considerations for RSVP Message-ID: <20030123115259.C84637-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 12:19:08 -0800 Message-ID: <3E304DF6.1070505@marconi.com> Date: Thu, 23 Jan 2003 15:17:58 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 MIME-Version: 1.0 To: GraIyMag@GraIyMage.com 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric Gray wrote: > > 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. I > can't say as I blame external organizations - who, in almost every case, > have mostly only seen the flames from prior efforts coloring the sky - > from opting to modify an existing protocol. > > We shouldn't chastise people for making what they feel are the best > choices based on the evidence in front of them. We should instead try > to determine what they are missing, or otherwise help them to modify > those choices. :-) You miss my point. I'm not saying that groups should always build new protocols. Sometimes, there are perfectly good reasons to extend an existing protocol (like GMPLS extended RSVP-TE). But when this is done, it should be done in conjunction with those responsible for the original protocol. A third-party (like IEEE, ITU, ATM Forum, ISO, etc.) should never grab an IETF protocol and make changes to it without involving the appropriate IETF group. (And I am not accusing any organization - these are just examples of the third parties I'm referring to. I am not talking about different groups within the IETF.) This goes the other way around as well. Just as IEEE would object to the IETF unilaterally defining an extension to FireWire (IEEE-1392) protocol, the IETF should similarly object to some outside organization unilaterally defining an extension to IP, or RSVP, etc. Now, I am not saying that every single third-party extension has done this. I am well aware of the fact that some groups do work with the IETF on their extensions. This is good. This is the way it should be. But there are other groups that do not. If your (now speaking to everybody reading this message) group's extension was developed in conjungtion with the IETF, then my criticism is not directed at you, and you should not take offense at my opinion. -- David Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 11:32:28 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97217E@nimbus> From: John Drake To: 'Stephen Trowbridge' , David Charlap Cc: 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 Date: Thu, 23 Jan 2003 11:31:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Stephen, I appreciate all the work you've done keep the IETF informed about what the ITU is doing. All I can say is that it doesn't seem to have worked. Rather than continuing to give us status reports on what the ITU is doing, I think it would make more sense to do the work in the appropriate IETF working groups. That was what I thought was the intent of the Feb 19th Liason: "We wish that as we continue our review of these protocols you will be able to provide us with recommendations on how to close these and future issues." However, a channel of communication has not been established: how should recommendations and issues be communicated? Who makes these, and who communicates them? How does a two-way (or n-way) dialog take place? If, on the other hand, these documents were brought into an IETF WG, the procedures and channels of communication exist and are well-known. Thanks, John -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Thursday, January 23, 2003 9:21 AM To: David Charlap Cc: 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 David, To read these emails, it sounds as though you think that the people who are doing this are brand new to the technology and never even considered working with IETF to try to solve the problem. Perhaps you haven't followed the ccamp work so closely, but here is some history: - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison statement regarding our new documents with requirements and architecture for switched (not necessarily IP) transport networks. This included a protocol- neutral model for call and connection management (signaling). In copies of the ITU-T documents were made available to non-ITU-T members via an ftp site. The liaison was placed on the IESG web site and was presented in the ccamp meeting in Salt Lake City in December. At that same meeting, Maarten Vissers gave a technical presentation in the sub-IP area meeting regarding the ITU-T work in this area. - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding the gaps that had been identified between the ITU-T requirements (sent earlier) and what seemed to be implemented by the GMPLS protocols. Specifically, 1. Call & Connection separation, e.g., a call provides the service relationship, which may support connection operations as part of a call. 2. Additional error codes/values, for example, for connection rejection (invalid connection ID). 3. Restart mechanisms: Depending on the introduction by the ITU of additional control plane resiliency requirements, enhancements of the protocol (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 4. Protocol enhancements in CR-LDP for support of crankback capability from intermediate nodes. This liaison was presented in the Minneapolis IETF meeting during the ccamp working group and posted on the IESG web site. The liaison requested assistance in closing these gaps and invited input from IETF on our work in ITU-T. - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, contributions were considered to close these gaps, resulting in text for draft Recommendations G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again, we sent a liaison (dated May 10, 2002) to ask for comments on our draft Recommendations (made available on the ftp site), to request alignment, and to ask for IANA code point assignments. To quote from that liaison: "Please consider including the proposed solutions provided in G.7713.2 and G.7713.3 to update the existing GMPLS signaling work in support of ASON requirements. We hope that you can help expedite the assignment of appropriate additional error codes/values by IANA. These are needed for both RSVP-TE and CR-LDP." This liaison was presented at the Yokohama IETF ccamp meeting. To refer to one point raised earlier in the thread, there are other cases where IANA has assigned codepoints for work outside of IETF, including other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last May, with no response. - Some final work was done on our drafts at a Rapporteur meeting in October, with one result being another liaison (dated October 11, 2002) making another plea for comments and help getting the codepoints assigned. This liaison was presented at the Atlanta IETF ccamp meeting, and still no response or IANA action. To hear now that someone thinks that the ASON work in ITU-T is some kind of secret end-run around IETF, and not involved with or related to the work being done internally in IETF is absurd. At every stage of the work, IETF was kept informed of the work and invited to participate. At the invitation for help to address the additional ITU-T requirements, there was no response. As ITU-T progressed this work and invited further comments and alignment of the base GMPLS protocols, again no response. And to the final pleas for comments and codepoint assignments, no response. I contrast this with our interaction with the ATM forum on the same topic. Certain operators in ITU-T are interested in using the PNNI protocol for this application (rather than rsvp-te or cr-ldp). The ATM forum has responded with a formal liaison into the current ITU-T Study Group 15 meeting where they have given us a diffmarked copy with extremely helpful and constructive suggestions about how to align our G.7713.1 document with their work. After some private communication with the Area directors, we received some advice that one tool that might be used to finally get the IANA codepoint assignment complete would be to publish what we were doing in ITU-T as informational RFCs. This is the stage we are at today, and given the history I describe above, I do not think anybody can say that we are at this point because any of us did not do everything possible to do this work (a) in IETF, with the initial communication of requirements; or (b) in cooperation between ITU-T and IETF, once this work had progressed in ITU-T. But this is all water under the bridge. We are at the point of trying to get some codepoints assigned for ITU-T documents we are trying to complete. Nobody should say "no" at this point because they think we didn't try to work this IN or WITH IETF first. It should be clear to all that this is not the case. Regards, Steve Trowbridge (vice-chairman, ITU-T Study Group 15) David Charlap wrote: > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 11:21:21 -0800 Message-ID: <3E304076.D5AF0CAF@lucent.com> Date: Thu, 23 Jan 2003 14:20:22 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Kireeti Kompella CC: "Lin, Zhi-Wei (Zhi)" , David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, > > 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"? > Well, it's my turn to beg to differ :) If you read the document && understand it && don't take any prejudice, then it may be more like specifying rules for using a protocol for an application with some hard requirements. Regards, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 11:08:32 -0800 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: Kireeti Kompella , David Charlap Cc: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 14:08:09 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kireeti, Please visit the IESG page, go to I-D tracker, and search under the document... If you don't know this site, here it is: https://datatracker.ietf.org/public/pidtracker.cgi Under filename, search for "draft-lin" Then hit the "Detail" button under the "In State: RFC Editor Queue" header. I guess some IETF WG chairs don't pay attention to this... Zhi -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, January 23, 2003 1:59 PM To: David Charlap Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; iana@ISI.EDU Subject: Re: IANA Considerations for RSVP > I must have struck a nerve here, because yours is the second response > I've gotten from somebody who thinks I'm referring to their specific > IETF-approved RSVP extension, even though I specifically said I'm > referring to extensions developed without IETF involvement. If you are under the impression that draft-lin-ccamp-gmpls-ason-rsvpte-04.txt is "IETF approved", I don't blame you. But in fact, it is not (yet). And even if it does get approval, it is as an *Informational* document. But you have struck a nerve with some (and a chord with me :-)) Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 11:05:17 -0800 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: Kireeti Kompella , "Lin, Zhi-Wei (Zhi)" Cc: David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 14:04:20 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kireeti, -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, January 23, 2003 1:53 PM To: Lin, Zhi-Wei (Zhi) Cc: David Charlap; Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com 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. 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"... > 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"? 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)... Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 11:00:05 -0800 Date: Thu, 23 Jan 2003 10:59:04 -0800 (PST) From: Kireeti Kompella To: David Charlap cc: Bob Braden , , , , Subject: Re: IANA Considerations for RSVP Message-ID: <20030123105357.M83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I must have struck a nerve here, because yours is the second response > I've gotten from somebody who thinks I'm referring to their specific > IETF-approved RSVP extension, even though I specifically said I'm > referring to extensions developed without IETF involvement. If you are under the impression that draft-lin-ccamp-gmpls-ason-rsvpte-04.txt is "IETF approved", I don't blame you. But in fact, it is not (yet). And even if it does get approval, it is as an *Informational* document. But you have struck a nerve with some (and a chord with me :-)) Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 10:53:29 -0800 Date: Thu, 23 Jan 2003 10:52:30 -0800 (PST) From: Kireeti Kompella To: "Lin, Zhi-Wei (Zhi)" cc: David Charlap , Bob Braden , , , , , , , Subject: RE: IANA Considerations for RSVP Message-ID: <20030123104246.W83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. > 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"? Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 10:43:31 -0800 Date: Thu, 23 Jan 2003 10:42:40 -0800 (PST) From: Kireeti Kompella To: David Charlap cc: Bob Braden , , , , Subject: Re: IANA Considerations for RSVP Message-ID: <20030123103757.B83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi David, On Thu, 23 Jan 2003, David Charlap wrote: > 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. Just notifying is insufficient. A detailed review, the ability to make comments and changes, going through the IETF process (such as it is) is MANDATORY for protocol changes. Moreover, making the spec standards track means that new specs can cite it *normatively*. > Not only isn't this happening, but there appears to be no desire to see > this happen. Well, it's like pulling teeth. But we're on the first step -- you can thank Bob for that! Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 10:39:10 -0800 Date: Thu, 23 Jan 2003 10:37:30 -0800 (PST) From: Kireeti Kompella To: David Charlap cc: , , , Subject: Re: IANA Considerations for RSVP Message-ID: <20030123103057.L83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi David, On Thu, 23 Jan 2003, David Charlap wrote: > Bob Braden wrote: > > > > There is a growing unease about IANA assignments of RSVP parameters -- > > object numbers, CTypes, message types, and error numbers -- for new > > uses of RSVP. Many of these IANA requests, but not all, originate > > outside the IETF in other standards bodies. Many of the people from > > outside the IETF were not part of the RSVP working group and so did not > > absorb the technical rationale behind RSVP; in fact, they are sometimes > > barely clued into IETF procedures at all. > > I've noticed the same thing. It seems that many non-IETF groups want to > use RSVP, and all believe that they must create extensions to the > protocol for their features, often without first bothering to check if > there are already obects defined by IETF standards that already serve > their purposes. And even in those cases where new objects may be > required, the proposed objects are often defined as having semantics > that differ greatly from the way RSVP usually operates. Glad to hear you say that! > 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. No comment :) > Unfortunately, I don't know what can be done about this. It's not that hard. As Bob said, redo the IANA Considerations (and not just for RSVP) to require *well* documented specs that go through tighter screening in the appropriate WGs. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:52:54 -0800 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: GraIyMag@graiymage.com, "Lin, Zhi-Wei (Zhi)" Cc: David Charlap , 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 Date: Thu, 23 Jan 2003 12:52:17 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:ewgray@graiymage.com] Sent: Thursday, January 23, 2003 12:43 PM To: Lin, Zhi-Wei (Zhi) Cc: David Charlap; 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 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... > ... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:21:53 -0800 Message-ID: <3E30248B.980C42B2@lucent.com> Date: Thu, 23 Jan 2003 10:21:15 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: David Charlap CC: 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, To read these emails, it sounds as though you think that the people who are doing this are brand new to the technology and never even considered working with IETF to try to solve the problem. Perhaps you haven't followed the ccamp work so closely, but here is some history: - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison statement regarding our new documents with requirements and architecture for switched (not necessarily IP) transport networks. This included a protocol- neutral model for call and connection management (signaling). In copies of the ITU-T documents were made available to non-ITU-T members via an ftp site. The liaison was placed on the IESG web site and was presented in the ccamp meeting in Salt Lake City in December. At that same meeting, Maarten Vissers gave a technical presentation in the sub-IP area meeting regarding the ITU-T work in this area. - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding the gaps that had been identified between the ITU-T requirements (sent earlier) and what seemed to be implemented by the GMPLS protocols. Specifically, 1. Call & Connection separation, e.g., a call provides the service relationship, which may support connection operations as part of a call. 2. Additional error codes/values, for example, for connection rejection (invalid connection ID). 3. Restart mechanisms: Depending on the introduction by the ITU of additional control plane resiliency requirements, enhancements of the protocol (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 4. Protocol enhancements in CR-LDP for support of crankback capability from intermediate nodes. This liaison was presented in the Minneapolis IETF meeting during the ccamp working group and posted on the IESG web site. The liaison requested assistance in closing these gaps and invited input from IETF on our work in ITU-T. - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, contributions were considered to close these gaps, resulting in text for draft Recommendations G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again, we sent a liaison (dated May 10, 2002) to ask for comments on our draft Recommendations (made available on the ftp site), to request alignment, and to ask for IANA code point assignments. To quote from that liaison: "Please consider including the proposed solutions provided in G.7713.2 and G.7713.3 to update the existing GMPLS signaling work in support of ASON requirements. We hope that you can help expedite the assignment of appropriate additional error codes/values by IANA. These are needed for both RSVP-TE and CR-LDP." This liaison was presented at the Yokohama IETF ccamp meeting. To refer to one point raised earlier in the thread, there are other cases where IANA has assigned codepoints for work outside of IETF, including other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last May, with no response. - Some final work was done on our drafts at a Rapporteur meeting in October, with one result being another liaison (dated October 11, 2002) making another plea for comments and help getting the codepoints assigned. This liaison was presented at the Atlanta IETF ccamp meeting, and still no response or IANA action. To hear now that someone thinks that the ASON work in ITU-T is some kind of secret end-run around IETF, and not involved with or related to the work being done internally in IETF is absurd. At every stage of the work, IETF was kept informed of the work and invited to participate. At the invitation for help to address the additional ITU-T requirements, there was no response. As ITU-T progressed this work and invited further comments and alignment of the base GMPLS protocols, again no response. And to the final pleas for comments and codepoint assignments, no response. I contrast this with our interaction with the ATM forum on the same topic. Certain operators in ITU-T are interested in using the PNNI protocol for this application (rather than rsvp-te or cr-ldp). The ATM forum has responded with a formal liaison into the current ITU-T Study Group 15 meeting where they have given us a diffmarked copy with extremely helpful and constructive suggestions about how to align our G.7713.1 document with their work. After some private communication with the Area directors, we received some advice that one tool that might be used to finally get the IANA codepoint assignment complete would be to publish what we were doing in ITU-T as informational RFCs. This is the stage we are at today, and given the history I describe above, I do not think anybody can say that we are at this point because any of us did not do everything possible to do this work (a) in IETF, with the initial communication of requirements; or (b) in cooperation between ITU-T and IETF, once this work had progressed in ITU-T. But this is all water under the bridge. We are at the point of trying to get some codepoints assigned for ITU-T documents we are trying to complete. Nobody should say "no" at this point because they think we didn't try to work this IN or WITH IETF first. It should be clear to all that this is not the case. Regards, Steve Trowbridge (vice-chairman, ITU-T Study Group 15) David Charlap wrote: > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:16:45 -0800 Date: Thu, 23 Jan 2003 12:15:21 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, braden@ISI.EDU, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Message-ID: <20030123171521.GC2000@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, braden@ISI.EDU, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sorry, accidentally narrowed the list. Date: Thu, 23 Jan 2003 12:08:11 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:10:51 -0800 Date: Thu, 23 Jan 2003 12:09:35 -0500 From: Scott W Brim To: Brian Hassink Cc: David Charlap , 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 Message-ID: <20030123170935.GB2000@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , Brian Hassink , David Charlap , 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:09:01 -0800 Date: Thu, 23 Jan 2003 12:08:11 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: IANA Considerations for RSVP Message-ID: <20030123170810.GA2000@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:07:12 -0800 Message-ID: <3E302109.1010200@ieee.org> Date: Thu, 23 Jan 2003 09:06:17 -0800 From: Jonathan Lang Reply-To: jplang@ieee.org User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 MIME-Version: 1.0 To: braden@ISI.EDU, rsvp@isi.edu, ccamp@ops.ietf.org Subject: [Fwd: Re: IANA Considerations for RSVP] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I accidentally omitted Bob, CCAMP, and rsvp list from my original response. Apologize in advance if you receive multiple copies. Thanks, Jonathan -------- Original Message -------- Subject: Re: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 08:33:14 -0800 From: Jonathan Lang Reply-To: jplang@ieee.org To: jplang@ieee.org CC: mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com References: <200301222140.VAA00937@gra.isi.edu> Bob, Bob Braden wrote: >Hardy friends who have stuck it out on the RSVP mailing list: > > > 3. The IANA Considerations draft should be published as an RFC, > perhaps after updating. Here are some issues that might affect > this update. > I concur. There needs to be an IANA Considerations draft published as an RFC. > > (A) How to handle requests for RSVP assignments for > extensions developed outside IETF? > > Here is my suggestion: > > For all assignments of numbers for extensions defined > in non-IETF standards bodies, the IANA should use > assignment names (e.g., object names) that are prefixed > with the name of the responsible standards body. For > example, the "SPIFFY_SESSION" object would become > "ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION", > etc., object. > This is fine, but I'm not sure it's enough. For example, the following text came from an email posted on the ietf discussion list by Zhi, the editor of "draft-lin-ccamp-gmpls-ason-rsvpte-04.txt", in response to a debate about this very issue. Last time I checked, the IETF didn't change the protocols, individuals did through contributions. The extensions requested for Call/Connection control were submitted by an individual. The fact the ITU weighed in requesting approval of the changes is a separate issue. So if this was an individual contribution, then it wouldn't be tagged "ITU-T_SPIFFY_SESSION"? > > (B) What policies should be imposed? > > The document currently divides the assignment space into > two subspaces, for "IETF Consensus" and "FCFS". RFC > 2434 lists various other possibilities; do we need any? > > Precisely what do we mean by IETF consensus? Does this > require a standards-track document? (We thought it did.) > > We assumed that non-IETF requests would necessarily go to > FCFS, but is it really FCFS + expert opinion? In other > words, how much oversight should we try to exert for > non-IETF RSVP extensions? I have seen some highly > questionable extensions. They tend to be micro-engineering, > with no sense of a larger design. > I would prefer that the majority of the assignments require standards-track documents. A few assignments could be left for "IETF Consensus", which I don't think requires standards track ID. And then a few assignements for "experimental". Thanks, Jonathan > > (C) What are the appropriate documentation requirements? > > 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. > >Bob Braden >Former co-chair of the RSVP WG >Current designated expert for RSVP assignments by IANA > > > >----- End Included Message ----- > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:03:02 -0800 Message-ID: From: "Mak, L (Leen)" To: "'David Charlap'" , Bob Braden Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, "Wijnen, Bert (Bert)" Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 18:01:15 +0100 MIME-Version: 1.0 Content-Type: text/plain 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 09:02:56 -0800 Message-ID: <3E301FF1.8080605@marconi.com> Date: Thu, 23 Jan 2003 12:01:37 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 MIME-Version: 1.0 To: "Lin, Zhi-Wei (Zhi)" 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lin, Zhi-Wei (Zhi) wrote: > > 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... I am not criticizing the existance of GMPLS or the CCAMP work that's being done. All of the IETF people involved in RSVP are aware of this and contribute to it as they feel necessary. I'm far more concerned with non-IETF groups (like ITU, ATM Forum and others) deciding to develop their own incompatible extensions without even informing any IETF groups of their actions. Groups like these should not be extending IETF protocols without consulting with the relevant IETF working groups. Otherwise we end up with extensions that duplicate existing IETF functionality, don't coexist gracefully, and/or break interoperability. And if these extensions become popular in products, the IETF will be forced to include them in the standards in order to prevent future IETF work from breaking them. > The extensions that's been requested were derived as a result of > discussions and efforts involving many IETF people as well (e.g., > please look at the author list of the OIF UNI document). Your comment > seems to suggest that the work appear out of nowhere with no > participation from the IETF RSVP experts...this is clearly not > true... I am not referring to OIF UNI. They are doing consulting with relevant IETF groups as a part of their work. I must have struck a nerve here, because yours is the second response I've gotten from somebody who thinks I'm referring to their specific IETF-approved RSVP extension, even though I specifically said I'm referring to extensions developed without IETF involvement. And I think that was Bob's original issue as well - since he explicitly mentioned IANA RSVP requests coming from non-IETF sources. -- David Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 08:49:22 -0800 Message-ID: <2135200C183FD5119588009027DE572302836BF4@webdev-owa.oni.com> From: "Ong, Lyndon" To: "'Lin, Zhi-Wei (Zhi)'" , David Charlap , Bob Braden Cc: 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 Date: Thu, 23 Jan 2003 08:48:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 08:42:46 -0800 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: David Charlap , 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, "Wesam Alanqar (E-mail)" , "Mark Jones (E-mail)" Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 11:42:14 -0500 MIME-Version: 1.0 Content-Type: text/plain 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: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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 08:32:47 -0800 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: David Charlap , Bob Braden Cc: 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 Date: Thu, 23 Jan 2003 11:31:59 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi David, This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols... 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... The extensions that's been requested were derived as a result of discussions and efforts involving many IETF people as well (e.g., please look at the author list of the OIF UNI document). Your comment seems to suggest that the work appear out of nowhere with no participation from the IETF RSVP experts...this is clearly not true... If you recall, throughout the development of the GMPLS RSVP-TE, the non-RSVP experts (I guess you would lump me in this category as well) provided major comments. As a non-RSVP expert, I tried my best to understand the original goal of RSVP; however, I did not make the initial decision to use RSVP for supporting control plane for transport network. This decision was made collectively by the sub-IP area and thus the GMPLS RSVP was born... But I think much of this is simply related to the current (lack of) process and procedural issues. These can be dealt with (possibly) at the next meeting, and a clear process should be put in place on how IETF would work with other standards organizations. But this is for the future... Zhi -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Thursday, January 23, 2003 10:56 AM To: Bob Braden Cc: 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 Bob Braden wrote: > > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. Many of these IANA requests, but not all, originate > outside the IETF in other standards bodies. Many of the people from > outside the IETF were not part of the RSVP working group and so did not > absorb the technical rationale behind RSVP; in fact, they are sometimes > barely clued into IETF procedures at all. I've noticed the same thing. It seems that many non-IETF groups want to use RSVP, and all believe that they must create extensions to the protocol for their features, often without first bothering to check if there are already obects defined by IETF standards that already serve their purposes. And even in those cases where new objects may be required, the proposed objects are often defined as having semantics that differ greatly from the way RSVP usually operates. 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. Personally, I don't like this. These groups should step back and decide if RSVP is really what they need. If they require a different protocol, then they should use a different protocol - they should not glom onto RSVP just because it's popular in MPLS and then try to change it into what they really want. This is especially true in those situations where their proposed changes would produce a fundamentally incompatible protocol. Unfortunately, I don't know what can be done about this. These groups seem hell-bent on hacking up RSVP without first learning it's design philosophy. If they don't get assignments from IANA, they'll probably just make their own assignments without any coordinating facility, and we'll wind up with several mutually incompatible protocols that all want to call themselves "RSVP". -- David Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 08:15:54 -0800 Message-ID: <3E301519.4010807@marconi.com> Date: Thu, 23 Jan 2003 11:15:21 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 MIME-Version: 1.0 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Jan 2003 07:58:11 -0800 Message-ID: <3E301086.3000002@marconi.com> Date: Thu, 23 Jan 2003 10:55:50 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 MIME-Version: 1.0 To: Bob Braden CC: 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bob Braden wrote: > > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. Many of these IANA requests, but not all, originate > outside the IETF in other standards bodies. Many of the people from > outside the IETF were not part of the RSVP working group and so did not > absorb the technical rationale behind RSVP; in fact, they are sometimes > barely clued into IETF procedures at all. I've noticed the same thing. It seems that many non-IETF groups want to use RSVP, and all believe that they must create extensions to the protocol for their features, often without first bothering to check if there are already obects defined by IETF standards that already serve their purposes. And even in those cases where new objects may be required, the proposed objects are often defined as having semantics that differ greatly from the way RSVP usually operates. 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. Personally, I don't like this. These groups should step back and decide if RSVP is really what they need. If they require a different protocol, then they should use a different protocol - they should not glom onto RSVP just because it's popular in MPLS and then try to change it into what they really want. This is especially true in those situations where their proposed changes would produce a fundamentally incompatible protocol. Unfortunately, I don't know what can be done about this. These groups seem hell-bent on hacking up RSVP without first learning it's design philosophy. If they don't get assignments from IANA, they'll probably just make their own assignments without any coordinating facility, and we'll wind up with several mutually incompatible protocols that all want to call themselves "RSVP". -- David Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 Jan 2003 19:51:13 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C903D7E631@main.mahinetworks.com> From: Abhimanyu Das To: "'ccamp@ops.ietf.org'" Subject: Control and data link association.. Date: Tue, 21 Jan 2003 19:48:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I had a question relating to control-link data-link associations in GMPLS. Is there an apriori association of data channels to specific control channels on a given node? Suppose two nodes have a single data link between them, but they have multiple IP control channels betwen them. Is there a requirement from a protocol perspective at a node, to specify and use only one particular IP control channel for the given data link, so that, for example, all signaling traffic related to that data link must travel over the specified control channel only? Or is it the case that control packets for the particular data link could be routed over any of the control channels between the two nodes, as long as the control packets reach the neighboring node.. Thanks, -Abhimanyu Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 20 Jan 2003 04:52:27 -0800 Message-Id: <200301201246.HAA17890@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-00.txt Date: Mon, 20 Jan 2003 07:46:45 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Analysis of Generalized MPLS-based Recovery Mechanisms (including Protection and Restoration) Author(s) : D. Papadimitriou, E. Mannie Filename : draft-ietf-ccamp-gmpls-recovery-analysis-00.txt Pages : 39 Date : 2003-1-17 This document provides an analysis grid that can be used to evaluate, compare and contrast the numerous Generalized MPLS (GMPLS)-based recovery mechanisms currently proposed at the CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in [CCAMP-TERM]. Also, this document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-17121301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-17121301.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 19 Jan 2003 15:31:56 -0800 Date: Sun, 19 Jan 2003 18:29:50 -0500 From: Ron Bonica Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, This message ends last call on draft-ietf-ccamp-lmp-test-sonet-sdh-00. (My appologies for not having sent this message on December 20). Ron > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com] > Sent: Friday, December 06, 2002 9:03 AM > To: ccamp@ops.ietf.org > Subject: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00 > > > Folks, > > This message begins a Working Group last call on > draft-ietf-ccamp-lmp-test-sonet-sdh-00. Last call will end two > weeks from today, on December 20, 2002. > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "We are not on Earth to guard a museum, but > to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Jan 2003 14:31:17 -0800 Message-ID: <3E25E0C2.D77C65E8@alcatel.be> Date: Wed, 15 Jan 2003 23:29:22 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) MIME-Version: 1.0 To: Charles Chen CC: "'ccamp@ops.ietf.org'" Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi see-line... Charles Chen wrote: > > Hi Dimitri, > > See inline, > > > > The second issue is how the core node identifies whether the > > > TE link configured, or discovered via LMP, is attached to > > an edge node. In > > > other words, does this need any support from LMP? > > > > since lmp allows the exchange of switching capability supported > > at the end-points (see lmp sect. 13.12.1.1), the use of method > > (described also in gmpls-routing) would deliver you links such > > that [PSC, LSC] refers to a link between a packet LSR and an OXC, > > we would then assume that this te link inter-connects an edge > > with a core node > > > > Whether a TE link is able to support more than one switching capability or > not has no relation to whether a node attached to it is a core > node or edge node. A core node which supports both LSR and OXC on a TE link > could > advertise it as both PSC and TDM. i think you took this as a "rule" why i have responded to a potential way to deliver this - i know that this may become an issue if multiple switching capabilities are supported => what you have to do is to select what you'd support for your edge node requests (the only complexity i see is when the client support more than one of these switching capabilities) > In addition, for any given LSP, all TE > links > associated with the LSP must have the same switching capability. from a signalling viewpoint it is today clearly indicated that "Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability." i don't know how you have inferred the above rule from this - also the lsp hierarchy drafts explains how to cross an lsp region in all its details (see section 7.1) in a sense what described in this document is how to emulate overlays thus the methods proposed there should be fine tunable in the context you describe here above > The > switching > capability is designed to faciliate the CSPF path selection for a given LSP > type (TDM, LSR, OXC, etc). your te link infers its own switching capability from the above thus it will become psc capable or whatever the edge node supports, it seems you took my example as a rule > Take one example, if an edge device attached to the TDM core network > supports two > types of client signals (TDM/SONET and Ethernet over SONET via X.86 or GFP) > for a "TDM" > LSP request, then I think the TE link attached to the edge device should > advertise > the switching capability of the TE link as TDM, and then use the g-pid to > represent the client > signal for a LSP request. It will be incorrect to say that the TE link in > question is > PSC, or anything else. once again you should read the above as an example (refer to gmpls-routing for more combinations - i refer you to the section 4.4.7 of gmpls-routing) thanks, - dimitri Charles Chen wrote: > > Hi Dimitri, > > See inline, > > > > The second issue is how the core node identifies whether the > > > TE link configured, or discovered via LMP, is attached to > > an edge node. In > > > other words, does this need any support from LMP? > > > > since lmp allows the exchange of switching capability supported > > at the end-points (see lmp sect. 13.12.1.1), the use of method > > (described also in gmpls-routing) would deliver you links such > > that [PSC, LSC] refers to a link between a packet LSR and an OXC, > > we would then assume that this te link inter-connects an edge > > with a core node > > > > Whether a TE link is able to support more than one switching capability or > not has no relation to whether a node attached to it is a core > node or edge node. A core node which supports both LSR and OXC on a TE link > could > advertise it as both PSC and TDM. In addition, for any given LSP, all TE > links > associated with the LSP must have the same switching capability. The > switching > capability is designed to faciliate the CSPF path selection for a given LSP > type (TDM, LSR, OXC, etc). > > Take one example, if an edge device attached to the TDM core network > supports two > types of client signals (TDM/SONET and Ethernet over SONET via X.86 or GFP) > for a "TDM" > LSP request, then I think the TE link attached to the edge device should > advertise > the switching capability of the TE link as TDM, and then use the g-pid to > represent the client > signal for a LSP request. It will be incorrect to say that the TE link in > question is > PSC, or anything else. > > Charles > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Wednesday, January 15, 2003 1:19 PM > > To: Charles Chen > > Cc: 'ccamp@ops.ietf.org' > > Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt > > > > > > hi charles, > > > > see in-line > > > > Charles Chen wrote: > > > > > > Is there any similar proposal of GMPLS routing support for > > the overlay > > > model? > > > There are a couple of issues that may need to be addressed. > > One is related > > > to > > > how the core node attached to one or more edge node > > advertises the TE links > > > between the edge core and the core node. In this case, for > > example, should > > > be the Link ID TLV > > > set to 0.0.0.0 or the same as the Router Address TLV, > > because there is no > > > peering router for > > > the TE link. > > > > this would then mean that you would consider such te links > > as part of the internal core domain instance > > > > > The second issue is how the core node identifies whether the > > > TE link configured, or discovered via LMP, is attached to > > an edge node. In > > > other words, does this need any support from LMP? > > > > since lmp allows the exchange of switching capability supported > > at the end-points (see lmp sect. 13.12.1.1), the use of method > > (described also in gmpls-routing) would deliver you links such > > that [PSC, LSC] refers to a link between a packet LSR and an OXC, > > we would then assume that this te link inter-connects an edge > > with a core node > > > > hope this helps, > > - dimitri. > > > > > Charles > > > > > > > -----Original Message----- > > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > Sent: Wednesday, January 15, 2003 4:59 AM > > > > Cc: > > > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. > > > > This draft is a work item of the Common Control and > > > > Measurement Plane Working Group of the IETF. > > > > > > > > Title : GMPLS RSVP Support for the Overlay Model > > > > Author(s) : G. Swallow et al. > > > > Filename : draft-ietf-ccamp-gmpls-overlay-00.txt > > > > Pages : 10 > > > > Date : 2003-1-13 > > > > > > > > Generalized MPLS defines both routing and signaling > > protocols for the > > > > creation of Label Switched Paths (LSPs) in various transport > > > > technologies. These protocols can be used to support a number of > > > > deployment scenarios. This memo addresses the > > application of GMPLS > > > > to the overlay model. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove > > > rlay-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a > > message to > > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-ccamp-gmpls-overlay-00.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before > > the "FILE" > > > command. To decode the response(s), you will need > > "munpack" or > > > a MIME-compliant mail reader. Different > > MIME-compliant mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which > > have been split > > > up into multiple messages), so check your local > > documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > -- > > 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 > > -- 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Jan 2003 13:47:27 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C9045DDA6B@main.mahinetworks.com> From: Charles Chen To: "'Dimitri.Papadimitriou@alcatel.be'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt Date: Wed, 15 Jan 2003 13:45:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Dimitri, See inline, > > The second issue is how the core node identifies whether the > > TE link configured, or discovered via LMP, is attached to > an edge node. In > > other words, does this need any support from LMP? > > since lmp allows the exchange of switching capability supported > at the end-points (see lmp sect. 13.12.1.1), the use of method > (described also in gmpls-routing) would deliver you links such > that [PSC, LSC] refers to a link between a packet LSR and an OXC, > we would then assume that this te link inter-connects an edge > with a core node > Whether a TE link is able to support more than one switching capability or not has no relation to whether a node attached to it is a core node or edge node. A core node which supports both LSR and OXC on a TE link could advertise it as both PSC and TDM. In addition, for any given LSP, all TE links associated with the LSP must have the same switching capability. The switching capability is designed to faciliate the CSPF path selection for a given LSP type (TDM, LSR, OXC, etc). Take one example, if an edge device attached to the TDM core network supports two types of client signals (TDM/SONET and Ethernet over SONET via X.86 or GFP) for a "TDM" LSP request, then I think the TE link attached to the edge device should advertise the switching capability of the TE link as TDM, and then use the g-pid to represent the client signal for a LSP request. It will be incorrect to say that the TE link in question is PSC, or anything else. Charles > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, January 15, 2003 1:19 PM > To: Charles Chen > Cc: 'ccamp@ops.ietf.org' > Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt > > > hi charles, > > see in-line > > Charles Chen wrote: > > > > Is there any similar proposal of GMPLS routing support for > the overlay > > model? > > There are a couple of issues that may need to be addressed. > One is related > > to > > how the core node attached to one or more edge node > advertises the TE links > > between the edge core and the core node. In this case, for > example, should > > be the Link ID TLV > > set to 0.0.0.0 or the same as the Router Address TLV, > because there is no > > peering router for > > the TE link. > > this would then mean that you would consider such te links > as part of the internal core domain instance > > > The second issue is how the core node identifies whether the > > TE link configured, or discovered via LMP, is attached to > an edge node. In > > other words, does this need any support from LMP? > > since lmp allows the exchange of switching capability supported > at the end-points (see lmp sect. 13.12.1.1), the use of method > (described also in gmpls-routing) would deliver you links such > that [PSC, LSC] refers to a link between a packet LSR and an OXC, > we would then assume that this te link inter-connects an edge > with a core node > > hope this helps, > - dimitri. > > > Charles > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Wednesday, January 15, 2003 4:59 AM > > > Cc: > > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > This draft is a work item of the Common Control and > > > Measurement Plane Working Group of the IETF. > > > > > > Title : GMPLS RSVP Support for the Overlay Model > > > Author(s) : G. Swallow et al. > > > Filename : draft-ietf-ccamp-gmpls-overlay-00.txt > > > Pages : 10 > > > Date : 2003-1-13 > > > > > > Generalized MPLS defines both routing and signaling > protocols for the > > > creation of Label Switched Paths (LSPs) in various transport > > > technologies. These protocols can be used to support a number of > > > deployment scenarios. This memo addresses the > application of GMPLS > > > to the overlay model. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove > > rlay-00.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-ccamp-gmpls-overlay-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before > the "FILE" > > command. To decode the response(s), you will need > "munpack" or > > a MIME-compliant mail reader. Different > MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which > have been split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > -- > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Jan 2003 13:21:38 -0800 Message-ID: <3E25D05E.C2070B7@alcatel.be> Date: Wed, 15 Jan 2003 22:19:26 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) MIME-Version: 1.0 To: Charles Chen CC: "'ccamp@ops.ietf.org'" Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi charles, see in-line Charles Chen wrote: > > Is there any similar proposal of GMPLS routing support for the overlay > model? > There are a couple of issues that may need to be addressed. One is related > to > how the core node attached to one or more edge node advertises the TE links > between the edge core and the core node. In this case, for example, should > be the Link ID TLV > set to 0.0.0.0 or the same as the Router Address TLV, because there is no > peering router for > the TE link. this would then mean that you would consider such te links as part of the internal core domain instance > The second issue is how the core node identifies whether the > TE link configured, or discovered via LMP, is attached to an edge node. In > other words, does this need any support from LMP? since lmp allows the exchange of switching capability supported at the end-points (see lmp sect. 13.12.1.1), the use of method (described also in gmpls-routing) would deliver you links such that [PSC, LSC] refers to a link between a packet LSR and an OXC, we would then assume that this te link inter-connects an edge with a core node hope this helps, - dimitri. > Charles > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, January 15, 2003 4:59 AM > > Cc: > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Common Control and > > Measurement Plane Working Group of the IETF. > > > > Title : GMPLS RSVP Support for the Overlay Model > > Author(s) : G. Swallow et al. > > Filename : draft-ietf-ccamp-gmpls-overlay-00.txt > > Pages : 10 > > Date : 2003-1-13 > > > > Generalized MPLS defines both routing and signaling protocols for the > > creation of Label Switched Paths (LSPs) in various transport > > technologies. These protocols can be used to support a number of > > deployment scenarios. This memo addresses the application of GMPLS > > to the overlay model. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove > rlay-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-overlay-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Jan 2003 10:42:42 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C9045DDA66@main.mahinetworks.com> From: Charles Chen To: "'ccamp@ops.ietf.org'" Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt Date: Wed, 15 Jan 2003 10:40:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Is there any similar proposal of GMPLS routing support for the overlay model? There are a couple of issues that may need to be addressed. One is related to how the core node attached to one or more edge node advertises the TE links between the edge core and the core node. In this case, for example, should be the Link ID TLV set to 0.0.0.0 or the same as the Router Address TLV, because there is no peering router for the TE link. The second issue is how the core node identifies whether the TE link configured, or discovered via LMP, is attached to an edge node. In other words, does this need any support from LMP? Charles > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, January 15, 2003 4:59 AM > Cc: > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Common Control and > Measurement Plane Working Group of the IETF. > > Title : GMPLS RSVP Support for the Overlay Model > Author(s) : G. Swallow et al. > Filename : draft-ietf-ccamp-gmpls-overlay-00.txt > Pages : 10 > Date : 2003-1-13 > > Generalized MPLS defines both routing and signaling protocols for the > creation of Label Switched Paths (LSPs) in various transport > technologies. These protocols can be used to support a number of > deployment scenarios. This memo addresses the application of GMPLS > to the overlay model. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove rlay-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-overlay-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Jan 2003 05:05:13 -0800 Message-Id: <200301151258.HAA24501@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt Date: Wed, 15 Jan 2003 07:58:58 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS RSVP Support for the Overlay Model Author(s) : G. Swallow et al. Filename : draft-ietf-ccamp-gmpls-overlay-00.txt Pages : 10 Date : 2003-1-13 Generalized MPLS defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-overlay-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-14144314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-overlay-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14144314.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 14 Jan 2003 07:20:37 -0800 Message-Id: <200301141512.KAA26259@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ccamp-gmpls-overlay-00.txt Date: Tue, 14 Jan 2003 10:12:21 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS RSVP Support for the Overlay Model Author(s) : G. Swallow et al. Filename : draft-ccamp-gmpls-overlay-00.txt Pages : 10 Date : 2003-1-13 Generalized MPLS defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ccamp-gmpls-overlay-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ccamp-gmpls-overlay-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ccamp-gmpls-overlay-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-13141844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ccamp-gmpls-overlay-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ccamp-gmpls-overlay-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13141844.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 10 Jan 2003 09:04:59 -0800 Message-ID: <3E1EFC95.13EB2898@alcatel.de> Date: Fri, 10 Jan 2003 18:02:14 +0100 From: Gert Grammel Organization: Alcatel TND Product Strategy MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: WG Consensus Call: Protection/restoration work Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit yes to both Cheers Gert Grammel > Hi All, > > Please comment on whether each of the following: > draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS > Recovery Functional Specification" > and > draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt > "Analysis of Generalized MPLS-based Recovery Mechanisms" > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 10 Jan 2003 06:16:18 -0800 Message-ID: <3E1ED47D.81C3C57C@alcatel.com> Date: Fri, 10 Jan 2003 15:11:09 +0100 From: Dominique.Verchere@alcatel.fr Reply-To: Dominique.Verchere@alcatel.com Organization: ALCATEL MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: WG Consensus Call: Protection/restoration work Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii yes and yes > Hi All, > > Please comment on whether each of the following: > draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS > Recovery Functional Specification" > and > draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt > "Analysis of Generalized MPLS-based Recovery Mechanisms" > > -- -------- Dominique Verchere mailto:Dominique.Verchere@alcatel.com ALCATEL CIT Research & Innovation URL: http://www.alcatel.com Route de Nozay tel: +33.1.69.63.4012 91461 Marcoussis Cedex, France fax: +33.1.69.63.1865