From 6bone-admin@mailman.isi.edu Wed Jan 1 08:10:16 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03756 for ; Wed, 1 Jan 2003 08:10:16 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h01DDRD09545 for ; Wed, 1 Jan 2003 05:13:27 -0800 (PST) Date: Wed, 1 Jan 2003 05:13:27 -0800 (PST) Message-Id: <200301011313.h01DDRD09545@gamma.isi.edu> Subject: mailman.isi.edu mailing list memberships reminder From: mailman-owner@mailman.isi.edu To: rsvp-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: 6bone-admin@mailman.isi.edu Errors-To: 6bone-admin@mailman.isi.edu X-BeenThere: 6bone@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk This is a reminder, sent out once a month, about your mailman.isi.edu mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rsvp-request@mailman.isi.edu) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.isi.edu. Thanks! Passwords for rsvp-archive@lists.ietf.org: List Password // URL ---- -------- rsvp@mailman.isi.edu aspugu http://mailman.isi.edu/mailman/options/rsvp/rsvp-archive%40lists.ietf.org From rsvp-admin@mailman.isi.edu Sat Jan 11 08:12:38 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11145 for ; Sat, 11 Jan 2003 08:12:38 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0BDFVD18031; Sat, 11 Jan 2003 05:15:31 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0B0jpD17706 for ; Fri, 10 Jan 2003 16:45:51 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0B0job20113 for ; Fri, 10 Jan 2003 16:45:50 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id AAA02874 for rsvp; Sat, 11 Jan 2003 00:45:50 GMT Message-Id: <200301110045.AAA02874@gra.isi.edu> To: rsvp@ISI.EDU X-Sun-Charset: US-ASCII Subject: [Rsvp] Request for IANA registration of new RSVP object Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sat, 11 Jan 2003 00:45:50 GMT Comments? Bob Braden -----Original Message----- From: ernie.tacsik@nokia.com [mailto:ernie.tacsik@nokia.com] Sent: Tuesday, October 22, 2002 1:46 PM To: iana@iana.org; ernie.tacsik@nokia.com Subject: General Request for Assignments Contact Name : ernie tacsik Contact Email : ernie.tacsik@nokia.com Type of Assignment : rsvp class-num / c-type. specifically 3GPP2_TFT object (or equivalent) Registry : rsvp Description : 3GPP2 is specifing an rsvp based protocol to signal qos related traffic flow templates. it would be highly desirable at this point to define a 3GPP2 specific object to carry these traffic flow templates from a mobile to a the core network for the purpose of flow mapping qos support Additional Info : rfc 2205 rsvp _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Wed Jan 22 16:05:08 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07103 for ; Wed, 22 Jan 2003 16:05:07 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0ML03D26219; Wed, 22 Jan 2003 13:00:03 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0MKTDD05981 for ; Wed, 22 Jan 2003 12:29:13 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0MKTCb06069 for ; Wed, 22 Jan 2003 12:29:12 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA00838 for rsvp; Wed, 22 Jan 2003 20:29:12 GMT Message-Id: <200301222029.UAA00838@gra.isi.edu> To: rsvp@ISI.EDU X-Sun-Charset: ISO-8859-1 Subject: [Rsvp] Question about RSVP spec Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Wed, 22 Jan 2003 20:29:12 GMT ----- Begin Included Message ----- From albanese@coritel.it Wed Jan 22 11:58:02 2003 From: "Roberto Albanese" To: Subject: Info RFC Date: Wed, 22 Jan 2003 20:58:20 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-AntiVirus: scanned by AMaViS 0.2.1 Good evening, i'm a student working on a thesis and í read the RFC 2205. I'd like to make you some questions about the SCOPE Object in RSVP protocol. I read that this Object " carries an explicit list of sender hosts towards which the information in the message is to be forwarded and may appear in a Resv, ResvErr, or ResvTear message". Is this Object copied in ResvErr from Resv? I'm thinking to implement a link failure signalling in an MPLS scenario: in first analysis i thought to use the SCOPE Object in which i could put all the SENDERs i'd like to inform about the failure, but this solution has problems: - ResvErr (not the PathErr) has the SCOPE Object and travels DOWNSTREAM; - Is this the real purpose of the SCOPE Object? Thanks in advance for your kind answer. Roberto Albanese ----- End Included Message ----- _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Wed Jan 22 16:54:13 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08851 for ; Wed, 22 Jan 2003 16:54:13 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0MLo7D17623; Wed, 22 Jan 2003 13:50:07 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0MLYLD10654 for ; Wed, 22 Jan 2003 13:34:21 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0MLYEb14611; Wed, 22 Jan 2003 13:34:14 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id VAA00918; Wed, 22 Jan 2003 21:34:14 GMT Message-Id: <200301222134.VAA00918@gra.isi.edu> To: rsvp@ISI.EDU Cc: braden@ISI.EDU, lixia@cs.ucla.edu, mankin@psg.com, sob@harvard.edu X-Sun-Charset: US-ASCII Subject: [Rsvp] Egads! Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Wed, 22 Jan 2003 21:34:14 GMT For curiosity, I just looked to see how many current Internet Drafts have "rvsp" in the title. The answer is: 59! Bob Braden gra 27% ls *rsvp* draft-atlas-rsvp-local-protect-interop-03.txt draft-bala-uni-ldp-rsvp-extensions-04.txt draft-brunner-nsis-rsvp2-00.txt draft-cai-ppvpn-vc-rsvp-te-01.txt draft-cai-rsvp-unknown-objects-01.txt draft-chang-mpls-rsvpte-path-protection-ext-03.txt draft-cheng-mpls-rsvp-multicast-er-01.txt draft-chung-mpls-rsvp-multicasting-01.txt draft-ehjoo-fr-rsvp-01.txt draft-fu-rsvp-multicast-analysis-01.txt draft-fujikawa-ric-srsvp-02.txt draft-greis-rsvp-analysis-01.txt draft-guo-rsvp-te-extensions-01.txt draft-ietf-issll-rsvp-aggr-04.txt draft-ietf-issll-rsvp-cap-04.txt draft-ietf-mpls-generalized-rsvp-te-09.txt draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt draft-ietf-mpls-rsvp-lsp-tunnel-09.txt draft-ietf-mpls-rsvp-tunnel-applicability-02.txt draft-ietf-mpls-rsvp-unnum-08.txt draft-ietf-nsis-rsvp-sec-properties-00.txt draft-ietf-rap-new-rsvp-ext-01.txt draft-ietf-rap-rsvp-authsession-05.txt draft-ietf-rap-rsvp-better-identity-02.txt draft-ietf-rap-rsvp-newidentity-02.txt draft-ietf-rap-rsvppcc-pib-02.txt draft-ietf-rsvp-fix-iana-00.txt draft-ietf-rsvp-proxy-03.txt draft-ietf-rsvp-refresh-reduct-05.txt draft-iovanna-rsvp-mpls-flowspec-01.txt draft-ishii-rsvp-te-ipv4-ipv6-extension-01.txt draft-lee-ccamp-rsvp-te-exclude-route-01.txt draft-lee-rsvp-te-exclude-route-01.txt draft-lin-ccamp-gmpls-ason-rsvpte-04.txt draft-liu-mpls-rsvp-shared-protection-00.txt draft-manner-lrsvp-01.txt draft-matsuura-gmpls-rsvp-requirements-01.txt draft-nitsan-cops-rsvp-proxy-04.txt draft-pan-rsvp-fastreroute-01.txt draft-pan-rsvp-te-restart-02.txt draft-paskalis-rsvpmp-01.txt draft-pelsser-rsvp-te-interdomain-lsp-00.ps draft-pelsser-rsvp-te-interdomain-lsp-00.txt draft-ping-rsvp-fastreroute-01.txt draft-rawlins-rsvppcc-pib-03.txt draft-shaheen-shahrier-nsis-brsvp-00.txt draft-shen-nsis-rsvp-mobileipv6-00.txt draft-shen-rsvp-mobileipv6-interop-01.txt draft-tempest-mpls-ccamp-rsvp-resync-01.txt draft-thomas-nsis-rsvp-analysis-00.txt draft-tschofenig-rsvp-sec-properties-00.txt draft-vasseur-mpls-computation-rsvp-03.txt draft-vijay-mpls-rsvpte-lspsubobject-01.txt draft-weijing-rsvp-sqn-01.txt draft-westberg-nsis-rsvp-as-ntlp-00.txt draft-westberg-proposal-for-rsvpv2-01.txt draft-yasukawa-mpls-rsvp-multicast-01.txt draft-yasukawa-mpls-rsvp-p2mp-00.txt draft-young-optical-prot-ext-rsvp-00.txt _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Wed Jan 22 16:54:20 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08868 for ; Wed, 22 Jan 2003 16:54:19 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0MLoAD17658; Wed, 22 Jan 2003 13:50:10 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0MLeMD13157 for ; Wed, 22 Jan 2003 13:40:22 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0MLeCb19161; Wed, 22 Jan 2003 13:40:12 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id VAA00937; Wed, 22 Jan 2003 21:40:12 GMT Message-Id: <200301222140.VAA00937@gra.isi.edu> To: rsvp@ISI.EDU 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 X-Sun-Charset: US-ASCII Subject: [Rsvp] IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Wed, 22 Jan 2003 21:40:12 GMT Hardy friends who have stuck it out on the RSVP mailing list: 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 ----- _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 08:14:50 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06494 for ; Thu, 23 Jan 2003 08:14:49 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NDI6D02733; Thu, 23 Jan 2003 05:18:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0N8YnD26901 for ; Thu, 23 Jan 2003 00:34:49 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0N8Ylb11268; Thu, 23 Jan 2003 00:34:47 -0800 (PST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h0N8YjM21633; Thu, 23 Jan 2003 09:34:45 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h0N8Yjq01643; Thu, 23 Jan 2003 09:34:45 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 09:34:44 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C8741@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Bob Braden'" , "'rsvp@ISI.EDU'" Subject: RE: [Rsvp] Request for IANA registration of new RSVP object MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 09:34:36 +0100 hi i briefly looked at the menioned rsvp document and i was quite surprised to see that rsvp is used to communicate between two hosts only (to deliver packet filter information). appart from the fact that this sounds like tist (a tist light version) the document does not use any particular rsvp features: - discovery mechanisms is replaced (no path message) - the typical signaling along the path covering more than two nodes is not present anymore - security is not mandated. if you install this type of information then you might want to be sure that is not modified, replayed, injected, etc. i think it is also allowed to remove packet filters which might cause some problems (that's why there is no such command is considered in the midcom protocols). especially the security issues seem to be hard if one looks at the discussions at the pana working group which more or less addresses similar issues. to me it seems that they are not sufficiently addressed in the document. ciao hannes > -----Original Message----- > From: rsvp-admin@mailman.isi.edu [mailto:rsvp-admin@mailman.isi.edu]On > Behalf Of Bob Braden > Sent: Saturday, January 11, 2003 1:46 AM > To: rsvp@ISI.EDU > Subject: [Rsvp] Request for IANA registration of new RSVP object > > > > Comments? > > Bob Braden > > > -----Original Message----- > From: ernie.tacsik@nokia.com [mailto:ernie.tacsik@nokia.com] > Sent: Tuesday, October 22, 2002 1:46 PM > To: iana@iana.org; ernie.tacsik@nokia.com > Subject: General Request for Assignments > > > Contact Name : > ernie tacsik > > Contact Email : > ernie.tacsik@nokia.com > > Type of Assignment : > rsvp class-num / c-type. specifically 3GPP2_TFT object (or > equivalent) > > Registry : > rsvp > > Description : > 3GPP2 is specifing an rsvp based protocol to signal qos > related traffic flow > templates. it would be highly desirable at this point to > define a 3GPP2 > specific object to carry these traffic flow templates from a > mobile to a the > core network for the purpose of flow mapping qos support > > Additional Info : > rfc 2205 rsvp > > _______________________________________________ > Rsvp mailing list > Rsvp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/rsvp _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 08:18:32 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06676 for ; Thu, 23 Jan 2003 08:18:31 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NDLqD03861; Thu, 23 Jan 2003 05:21:52 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NBwGD13126 for ; Thu, 23 Jan 2003 03:58:16 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NBwEb01896; Thu, 23 Jan 2003 03:58:14 -0800 (PST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h0NBoxM22758; Thu, 23 Jan 2003 12:50:59 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h0NBowq14466; Thu, 23 Jan 2003 12:50:58 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 12:50:57 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C8748@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Bob Braden'" , "'rsvp@ISI.EDU'" , "'hemanth_khare@rediffmail.com'" Cc: "'schultz@io.iol.unh.edu'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: doubt Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 12:50:56 +0100 hi bob! sometimes it would be good if a error message (such as a path error) is only send to an intermediate host. you might remember the security discussion where a path message hits a node (the path msg contains an integrity object) but unfortunately the path changed and the cryptographic verification fails. hence the path message is returned to the data sender which is of no help. example: /-------> b a ---- \-------> c router a forwards a path message and includes an integrity object. he assumes that the message is send to router b. unfortunately it is send to router c (because of a route change). imagine there is an entire network between a and b/c. hence cryptopgraphic verification fails at router c. he transmits a path error message back to the data source. this verification failure is only a problem between the participating routers. Ideally, router a would recognize this path change and would add a new integrity object with the security association shared with router c. ciao hannes > -----Original Message----- > From: owner-rsvp@ISI.EDU [mailto:owner-rsvp@ISI.EDU]On Behalf Of Bob > Braden > Sent: Tuesday, September 17, 2002 12:01 AM > To: rsvp@ISI.EDU; hemanth_khare@rediffmail.com > Cc: schultz@io.iol.unh.edu > Subject: Re: doubt > > > *> After reading this section what i have in mind is > that error in > *> the PERR message will be reported to the sender (data source). > *> > *> But the error may be caused by the intermediate > nodes. In that > *> case error must be reported intermediate node and not to sender > *> application (data source). > *> > > What good would it do to notify intermediate nodes, when the > error is caused by erroneous data from the sender RSVP? > Only the sender is in a position to correct the error. > > Bob Braden > > *> Please let me know ur thoughts on this aspect. > *> > *> TIA and Regards, > *> -hemanth > *> __________________________________________________________ > *> Give your Company an email address like > *> ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > *> Know more. http://www.rediffmailpro.com/signup/ > *> _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 11:04:21 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11317 for ; Thu, 23 Jan 2003 11:04:20 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NG04D20744; Thu, 23 Jan 2003 08:00:04 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NFu6D18757 for ; Thu, 23 Jan 2003 07:56:06 -0800 (PST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NFu5b25172; Thu, 23 Jan 2003 07:56:05 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03027; Thu, 23 Jan 2003 10:55:15 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12810; Thu, 23 Jan 2003 10:55:14 -0500 (EST) Message-ID: <3E301086.3000002@marconi.com> From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he 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 References: <200301222140.VAA00937@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 10:55:50 -0500 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 11:16:54 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11993 for ; Thu, 23 Jan 2003 11:16:53 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGKED29376; Thu, 23 Jan 2003 08:20:14 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGFZD27283 for ; Thu, 23 Jan 2003 08:15:35 -0800 (PST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGFXb05513; Thu, 23 Jan 2003 08:15:34 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04385; Thu, 23 Jan 2003 11:14:45 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17186; Thu, 23 Jan 2003 11:14:45 -0500 (EST) Message-ID: <3E301519.4010807@marconi.com> From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he 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 References: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 11:15:21 -0500 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 13:36:54 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16069 for ; Thu, 23 Jan 2003 13:36:53 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIeDD09981; Thu, 23 Jan 2003 10:40:13 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIbaD08198 for ; Thu, 23 Jan 2003 10:37:36 -0800 (PST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIbZb24741; Thu, 23 Jan 2003 10:37:35 -0800 (PST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIbUS65089; Thu, 23 Jan 2003 10:37:30 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIbU484088; Thu, 23 Jan 2003 10:37:30 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: David Charlap cc: , , , In-Reply-To: <3E301086.3000002@marconi.com> Message-ID: <20030123103057.L83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 10:37:30 -0800 (PST) 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. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 13:49:13 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16345 for ; Thu, 23 Jan 2003 13:49:13 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIj7D11876; Thu, 23 Jan 2003 10:45:07 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIgkD10320 for ; Thu, 23 Jan 2003 10:42:46 -0800 (PST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIgjb27249; Thu, 23 Jan 2003 10:42:45 -0800 (PST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIgeS65549; Thu, 23 Jan 2003 10:42:40 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIge884144; Thu, 23 Jan 2003 10:42:40 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: David Charlap cc: Bob Braden , , , , In-Reply-To: <3E301519.4010807@marconi.com> Message-ID: <20030123103757.B83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 10:42:40 -0800 (PST) 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. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 14:04:16 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16742 for ; Thu, 23 Jan 2003 14:04:16 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJ08D21208; Thu, 23 Jan 2003 11:00:08 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIxBD20457 for ; Thu, 23 Jan 2003 10:59:11 -0800 (PST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIxAb06302; Thu, 23 Jan 2003 10:59:10 -0800 (PST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIx4S67131; Thu, 23 Jan 2003 10:59:04 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIx4p84293; Thu, 23 Jan 2003 10:59:04 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: David Charlap cc: Bob Braden , , , , In-Reply-To: <3E301FF1.8080605@marconi.com> Message-ID: <20030123105357.M83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 10:59:04 -0800 (PST) > 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. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Thu Jan 23 15:24:45 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19256 for ; Thu, 23 Jan 2003 15:24:44 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NKKED29082; Thu, 23 Jan 2003 12:20:14 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NKIND28559 for ; Thu, 23 Jan 2003 12:18:24 -0800 (PST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NKIJb17185; Thu, 23 Jan 2003 12:18:20 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16874; Thu, 23 Jan 2003 15:17:22 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28631; Thu, 23 Jan 2003 15:17:22 -0500 (EST) Message-ID: <3E304DF6.1070505@marconi.com> From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he 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 References: <200301222140.VAA00937@gra.isi.edu> <3E301086.3000002@marconi.com> <3E30260A.82698500@GraIyMage.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 15:17:58 -0500 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Fri Jan 24 08:16:38 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17742 for ; Fri, 24 Jan 2003 08:16:37 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0ODJqD23411; Fri, 24 Jan 2003 05:19:52 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0O7bMD01137 for ; Thu, 23 Jan 2003 23:37:22 -0800 (PST) Received: from bob.isi.edu (c-24-30-109-77.we.client2.attbi.com [24.30.109.77]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0O7bLb00314; Thu, 23 Jan 2003 23:37:21 -0800 (PST) Received: from bob.isi.edu (localhost.localdomain [127.0.0.1]) by bob.isi.edu (8.12.5/8.12.5) with ESMTP id h0O7b9N5004256; Thu, 23 Jan 2003 23:37:09 -0800 Received: from bob.isi.edu (lindell@localhost) by bob.isi.edu (8.12.5/8.12.5/Submit) with ESMTP id h0O7b98l004250; Thu, 23 Jan 2003 23:37:09 -0800 Message-Id: <200301240737.h0O7b98l004250@bob.isi.edu> To: Tschofenig Hannes cc: "'Bob Braden'" , "'rsvp@ISI.EDU'" , "'hemanth_khare@rediffmail.com'" , "'schultz@io.iol.unh.edu'" Reply-To: lindell@ISI.EDU Subject: Re: [Rsvp] RE: doubt In-Reply-To: Message from Tschofenig Hannes of "Thu, 23 Jan 2003 12:50:56 +0100." <2A8DB02E3018D411901B009027FD3A3F034C8748@mchp905a.mch.sbs.de> From: Bob Lindell Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 23:37:09 -0800 > hi bob! > > sometimes it would be good if a error message (such as a path error) is only > send to an intermediate host. you might remember the security discussion > where a path message hits a node (the path msg contains an integrity object) > but unfortunately the path changed and the cryptographic verification fails. > hence the path message is returned to the data sender which is of no help. Why is the path message "returned"? A packet that fails cryptographic authentication is dropped. Why should an implementation assume that a message with an incorrect digest contains a valid message type (e.g. a PATH message)? > > example: > > /-------> b > a ---- > \-------> c > > router a forwards a path message and includes an integrity object. he > assumes that the message is send to router b. unfortunately it is send to > router c (because of a route change). imagine there is an entire network > between a and b/c. > > hence cryptopgraphic verification fails at router c. he transmits a path > error message back to the data source. this verification failure is only a > problem between the participating routers. Ideally, router a would recognize > this path change and would add a new integrity object with the security > association shared with router c. All potential receivers should be configured to share a security association with a sender LIH. Non-RSVP clouds can make this configuration more complex than would be desired. Such is life. Bob Lindell > > ciao > hannes > > > > -----Original Message----- > > From: owner-rsvp@ISI.EDU [mailto:owner-rsvp@ISI.EDU]On Behalf Of Bob > > Braden > > Sent: Tuesday, September 17, 2002 12:01 AM > > To: rsvp@ISI.EDU; hemanth_khare@rediffmail.com > > Cc: schultz@io.iol.unh.edu > > Subject: Re: doubt > > > > > > *> After reading this section what i have in mind is > > that error in > > *> the PERR message will be reported to the sender (data source). > > *> > > *> But the error may be caused by the intermediate > > nodes. In that > > *> case error must be reported intermediate node and not to sender > > *> application (data source). > > *> > > > > What good would it do to notify intermediate nodes, when the > > error is caused by erroneous data from the sender RSVP? > > Only the sender is in a position to correct the error. > > > > Bob Braden > > > > *> Please let me know ur thoughts on this aspect. > > *> > > *> TIA and Regards, > > *> -hemanth > > *> __________________________________________________________ > > *> Give your Company an email address like > > *> ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > > *> Know more. http://www.rediffmailpro.com/signup/ > > *> > _______________________________________________ > Rsvp mailing list > Rsvp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/rsvp _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Fri Jan 24 11:48:51 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24613 for ; Fri, 24 Jan 2003 11:48:50 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OGq0D06285; Fri, 24 Jan 2003 08:52:00 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OGnnD05628 for ; Fri, 24 Jan 2003 08:49:50 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0OGnlb13703; Fri, 24 Jan 2003 08:49:47 -0800 (PST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h0OGfKG10726; Fri, 24 Jan 2003 17:41:20 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h0OGfKq02303; Fri, 24 Jan 2003 17:41:20 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 17:41:19 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C8762@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'lindell@ISI.EDU'" Cc: "'Bob Braden'" , "'rsvp@ISI.EDU'" , "'hemanth_khare@rediffmail.com'" , "'schultz@io.iol.unh.edu'" Subject: RE: [Rsvp] RE: doubt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 17:41:19 +0100 hallo thanks for sharing your thoughts with me. please see my comments inline: > > > hi bob! > > > > sometimes it would be good if a error message (such as a > path error) is only > > send to an intermediate host. you might remember the > security discussion > > where a path message hits a node (the path msg contains an > integrity object) > > but unfortunately the path changed and the cryptographic > verification fails. > > hence the path message is returned to the data sender which > is of no help. > > Why is the path message "returned"? A packet that fails cryptographic > authentication is dropped. Why should an implementation assume that > a message with an incorrect digest contains a valid message type (e.g. > a PATH message)? if you assume that a rsvp node is always able to select the correct security association (and key) to protect the signaling message transmitted to the next rsvp node then you are done with it. the question is therefore whether an rsvp node always knows its next rsvp aware router along the path. if it doesn't know it then it cannot secure the message. > > > > > example: > > > > /-------> b > > a ---- > > \-------> c > > > > router a forwards a path message and includes an integrity > object. he > > assumes that the message is send to router b. unfortunately > it is send to > > router c (because of a route change). imagine there is an > entire network > > between a and b/c. > > > > hence cryptopgraphic verification fails at router c. he > transmits a path > > error message back to the data source. this verification > failure is only a > > problem between the participating routers. Ideally, router > a would recognize > > this path change and would add a new integrity object with > the security > > association shared with router c. > > All potential receivers should be configured to share a security > association with a sender LIH. Non-RSVP clouds can make this > configuration more complex than would be desired. Such is life. sounds simple. additionally to the availablity of the keys you still have to know the next rsvp node to select the correct one. if you fail then you don't even recognize it (since you drop the message silently). imagine an rsvp signaling message which is processed at the access networks (because they are rsvp aware). the core networks are non-rsvp clouds. when the rsvp path message leaves the access network of the data sender it will be interpreted at the receiver's access network (edge router). two things sound difficult for me: - how to establish the keys between these large number of networks - how to know which router will be hit at the other access network before transmitting the message to avoid selecting the wrong key ciao hannes > > > Bob Lindell > > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: owner-rsvp@ISI.EDU [mailto:owner-rsvp@ISI.EDU]On > Behalf Of Bob > > > Braden > > > Sent: Tuesday, September 17, 2002 12:01 AM > > > To: rsvp@ISI.EDU; hemanth_khare@rediffmail.com > > > Cc: schultz@io.iol.unh.edu > > > Subject: Re: doubt > > > > > > > > > *> After reading this section what i have in mind is > > > that error in > > > *> the PERR message will be reported to the sender > (data source). > > > *> > > > *> But the error may be caused by the intermediate > > > nodes. In that > > > *> case error must be reported intermediate node and > not to sender > > > *> application (data source). > > > *> > > > > > > What good would it do to notify intermediate nodes, when the > > > error is caused by erroneous data from the sender RSVP? > > > Only the sender is in a position to correct the error. > > > > > > Bob Braden > > > > > > *> Please let me know ur thoughts on this aspect. > > > *> > > > *> TIA and Regards, > > > *> -hemanth > > > *> __________________________________________________________ > > > *> Give your Company an email address like > > > *> ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > > > *> Know more. http://www.rediffmailpro.com/signup/ > > > *> > > _______________________________________________ > > Rsvp mailing list > > Rsvp@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/rsvp > _______________________________________________ > Rsvp mailing list > Rsvp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/rsvp > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Fri Jan 24 12:26:55 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25496 for ; Fri, 24 Jan 2003 12:26:54 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OHU5D26361; Fri, 24 Jan 2003 09:30:05 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OHTSD26322 for ; Fri, 24 Jan 2003 09:29:28 -0800 (PST) Received: from bob.isi.edu (bob.isi.edu [128.9.160.217]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0OHTRb05319; Fri, 24 Jan 2003 09:29:27 -0800 (PST) Received: from bob.isi.edu (localhost.localdomain [127.0.0.1]) by bob.isi.edu (8.12.5/8.12.5) with ESMTP id h0OHTOfq002354; Fri, 24 Jan 2003 09:29:24 -0800 Received: from bob.isi.edu (lindell@localhost) by bob.isi.edu (8.12.5/8.12.5/Submit) with ESMTP id h0OHTO6F002348; Fri, 24 Jan 2003 09:29:24 -0800 Message-Id: <200301241729.h0OHTO6F002348@bob.isi.edu> To: Tschofenig Hannes cc: "'Bob Braden'" , "'rsvp@ISI.EDU'" , "'hemanth_khare@rediffmail.com'" , "'schultz@io.iol.unh.edu'" Reply-To: lindell@ISI.EDU Subject: Re: [Rsvp] RE: doubt In-Reply-To: Message from Tschofenig Hannes of "Fri, 24 Jan 2003 17:41:19 +0100." <2A8DB02E3018D411901B009027FD3A3F034C8762@mchp905a.mch.sbs.de> From: Bob Lindell Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 09:29:24 -0800 > hallo > > thanks for sharing your thoughts with me. please see my comments inline: > > > > > > hi bob! > > > > > > sometimes it would be good if a error message (such as a > > path error) is only > > > send to an intermediate host. you might remember the > > security discussion > > > where a path message hits a node (the path msg contains an > > integrity object) > > > but unfortunately the path changed and the cryptographic > > verification fails. > > > hence the path message is returned to the data sender which > > is of no help. > > > > Why is the path message "returned"? A packet that fails cryptographic > > authentication is dropped. Why should an implementation assume that > > a message with an incorrect digest contains a valid message type (e.g. > > a PATH message)? > > if you assume that a rsvp node is always able to select the correct security > association (and key) to protect the signaling message transmitted to the > next rsvp node then you are done with it. That was the assumption when we wrote the RFC. > > the question is therefore whether an rsvp node always knows its next rsvp > aware router along the path. if it doesn't know it then it cannot secure the > message. that is correct. > > > > > > > > > example: > > > > > > /-------> b > > > a ---- > > > \-------> c > > > > > > router a forwards a path message and includes an integrity > > object. he > > > assumes that the message is send to router b. unfortunately > > it is send to > > > router c (because of a route change). imagine there is an > > entire network > > > between a and b/c. > > > > > > hence cryptopgraphic verification fails at router c. he > > transmits a path > > > error message back to the data source. this verification > > failure is only a > > > problem between the participating routers. Ideally, router > > a would recognize > > > this path change and would add a new integrity object with > > the security > > > association shared with router c. > > > > All potential receivers should be configured to share a security > > association with a sender LIH. Non-RSVP clouds can make this > > configuration more complex than would be desired. Such is life. > > sounds simple. additionally to the availablity of the keys you still have to > know the next rsvp node to select the correct one. if you fail then you > don't even recognize it (since you drop the message silently). yes > > imagine an rsvp signaling message which is processed at the access networks > (because they are rsvp aware). the core networks are non-rsvp clouds. when > the rsvp path message leaves the access network of the data sender it will > be interpreted at the receiver's access network (edge router). > > two things sound difficult for me: > - how to establish the keys between these large number of networks > - how to know which router will be hit at the other access network before > transmitting the message to avoid selecting the wrong key Remember, this is hop-by-hop integrity. If you define a single hop as crossing the core of the Internet, then you have substantially changed the model of RSVP deployment. How do you guarantee any level of QoS in the core? Internet scale key management issues are more in the domain of RSVP policy objects. When signalling requests are passed from one domain to another domain, there needs to be a mechanism to authenticate and authorize the request (and bill the customer). Simple hop-by-hop message integrity mechanisms are not meant to address those problems. Bob Lindell > > > ciao > hannes > > > > > > > > Bob Lindell > > > > > > > > ciao > > > hannes > > > > > > > > > > -----Original Message----- > > > > From: owner-rsvp@ISI.EDU [mailto:owner-rsvp@ISI.EDU]On > > Behalf Of Bob > > > > Braden > > > > Sent: Tuesday, September 17, 2002 12:01 AM > > > > To: rsvp@ISI.EDU; hemanth_khare@rediffmail.com > > > > Cc: schultz@io.iol.unh.edu > > > > Subject: Re: doubt > > > > > > > > > > > > *> After reading this section what i have in mind is > > > > that error in > > > > *> the PERR message will be reported to the sender > > (data source). > > > > *> > > > > *> But the error may be caused by the intermediate > > > > nodes. In that > > > > *> case error must be reported intermediate node and > > not to sender > > > > *> application (data source). > > > > *> > > > > > > > > What good would it do to notify intermediate nodes, when the > > > > error is caused by erroneous data from the sender RSVP? > > > > Only the sender is in a position to correct the error. > > > > > > > > Bob Braden > > > > > > > > *> Please let me know ur thoughts on this aspect. > > > > *> > > > > *> TIA and Regards, > > > > *> -hemanth > > > > *> __________________________________________________________ > > > > *> Give your Company an email address like > > > > *> ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > > > > *> Know more. http://www.rediffmailpro.com/signup/ > > > > *> > > > _______________________________________________ > > > Rsvp mailing list > > > Rsvp@mailman.isi.edu > > > http://mailman.isi.edu/mailman/listinfo/rsvp > > _______________________________________________ > > Rsvp mailing list > > Rsvp@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/rsvp > > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Fri Jan 24 13:16:53 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27209 for ; Fri, 24 Jan 2003 13:16:53 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OIK6D22821; Fri, 24 Jan 2003 10:20:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OIG2D21451 for ; Fri, 24 Jan 2003 10:16:02 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0OIG0b06111; Fri, 24 Jan 2003 10:16:00 -0800 (PST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h0OHrTG11624; Fri, 24 Jan 2003 18:53:29 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h0OHrTq01774; Fri, 24 Jan 2003 18:53:29 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 18:53:28 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C876D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'lindell@ISI.EDU'" Cc: "'Bob Braden'" , "'rsvp@ISI.EDU'" , "'hemanth_khare@rediffmail.com'" , "'schultz@io.iol.unh.edu'" Subject: RE: [Rsvp] RE: doubt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 18:53:26 +0100 hi > > That was the assumption when we wrote the RFC. > > Remember, this is hop-by-hop integrity. If you define a single hop > as crossing the core of the Internet, then you have substantially > changed the model of RSVP deployment. How do you guarantee any > level of QoS in the core? i guess that this is the source of the problem. the assumtion was fine when designing rsvp as a signaling protocol for intserv. however, people have added extensions to the protocol and used the protocol for different things. in these scenarios / environments this assumption does not necessarily hold. unfortunately people tend to extend the functionality but forget to look at the security again (the only reference the original security documents). that's not your fault for sure. > > Internet scale key management issues are more in the domain of RSVP > policy objects. When signalling requests are passed from one domain > to another domain, there needs to be a mechanism to authenticate > and authorize the request (and bill the customer). Simple hop-by-hop > message integrity mechanisms are not meant to address those problems. my personal opinion: the policy objects tried to repair the missing key management to some extend (i.e. they provide the user identity for the purpose of policy based admission control). the hop-by-hop security is perfectly fine for the charging model currently used in the internet. i will send around a document giving detailed reasons for this statement in the near future. ciao hannes > > Bob Lindell > > > > > > > ciao > > hannes > > > > > > > > > > > > > Bob Lindell > > > > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-rsvp@ISI.EDU [mailto:owner-rsvp@ISI.EDU]On > > > Behalf Of Bob > > > > > Braden > > > > > Sent: Tuesday, September 17, 2002 12:01 AM > > > > > To: rsvp@ISI.EDU; hemanth_khare@rediffmail.com > > > > > Cc: schultz@io.iol.unh.edu > > > > > Subject: Re: doubt > > > > > > > > > > > > > > > *> After reading this section what i have in mind is > > > > > that error in > > > > > *> the PERR message will be reported to the sender > > > (data source). > > > > > *> > > > > > *> But the error may be caused by the intermediate > > > > > nodes. In that > > > > > *> case error must be reported intermediate node and > > > not to sender > > > > > *> application (data source). > > > > > *> > > > > > > > > > > What good would it do to notify intermediate nodes, when the > > > > > error is caused by erroneous data from the sender RSVP? > > > > > Only the sender is in a position to correct the error. > > > > > > > > > > Bob Braden > > > > > > > > > > *> Please let me know ur thoughts on this aspect. > > > > > *> > > > > > *> TIA and Regards, > > > > > *> -hemanth > > > > > *> > __________________________________________________________ > > > > > *> Give your Company an email address like > > > > > *> ravi @ ravi-exports.com. Sign up for Rediffmail > Pro today! > > > > > *> Know more. http://www.rediffmailpro.com/signup/ > > > > > *> > > > > _______________________________________________ > > > > Rsvp mailing list > > > > Rsvp@mailman.isi.edu > > > > http://mailman.isi.edu/mailman/listinfo/rsvp > > > _______________________________________________ > > > Rsvp mailing list > > > Rsvp@mailman.isi.edu > > > http://mailman.isi.edu/mailman/listinfo/rsvp > > > > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Fri Jan 24 14:11:53 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29124 for ; Fri, 24 Jan 2003 14:11:52 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OJF4D16930; Fri, 24 Jan 2003 11:15:04 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OJAbD15191 for ; Fri, 24 Jan 2003 11:10:37 -0800 (PST) Received: from bob.isi.edu (bob.isi.edu [128.9.160.217]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0OJAab06468; Fri, 24 Jan 2003 11:10:36 -0800 (PST) Received: from bob.isi.edu (localhost.localdomain [127.0.0.1]) by bob.isi.edu (8.12.5/8.12.5) with ESMTP id h0OJAZfq003791; Fri, 24 Jan 2003 11:10:35 -0800 Received: from bob.isi.edu (lindell@localhost) by bob.isi.edu (8.12.5/8.12.5/Submit) with ESMTP id h0OJAYG3003785; Fri, 24 Jan 2003 11:10:34 -0800 Message-Id: <200301241910.h0OJAYG3003785@bob.isi.edu> To: Tschofenig Hannes cc: "'Bob Braden'" , "'rsvp@ISI.EDU'" , "'hemanth_khare@rediffmail.com'" , "'schultz@io.iol.unh.edu'" Reply-To: lindell@ISI.EDU Subject: Re: [Rsvp] RE: doubt In-Reply-To: Message from Tschofenig Hannes of "Fri, 24 Jan 2003 18:53:26 +0100." <2A8DB02E3018D411901B009027FD3A3F034C876D@mchp905a.mch.sbs.de> From: Bob Lindell Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 11:10:34 -0800 > my personal opinion: the policy objects tried to repair the missing key > management to some extend (i.e. they provide the user identity for the > purpose of policy based admission control). No. Policy and hop-by-hop integrity perform complementary functions. Hop-by-hop integrity authenticates that the message came from a trusted neighboring router in the signaling path and that the contents have not been modified in-route. Policy identifies the sender of the request and is the basis for policy based admission control and charging. A sender gets charged for a request, not an intermediate router in the signaling path. > > the hop-by-hop security is perfectly fine for the charging model currently > used in the internet. i will send around a document giving detailed reason > s > for this statement in the near future. No. See above. Bob _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:11:53 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29919 for ; Sat, 25 Jan 2003 19:11:53 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FDD16495; Sat, 25 Jan 2003 16:15:13 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGgJD06844 for ; Thu, 23 Jan 2003 08:42:19 -0800 (PST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGgHb16778; Thu, 23 Jan 2003 08:42:17 -0800 (PST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NGgFs21827; Thu, 23 Jan 2003 11:42:16 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 11:42:15 -0500 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)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 11:42:14 -0500 Hi David, I responded to an earlier message (you probably haven't seen it yet), but I just want to re-iterate some points here, especially the point about not wanting to work together. I'm not sure whether you've followed the work in CCAMP WG, but I've made the point that the ITU-T has notified and provided status as well as their "draft" documents to IETF consistently and regularly for the last few IEFT CCAMP WG meetings. As such, your point that you gave below I take it to imply that you either (1) have not followed the recent work in CCAMP, or (2) you choose to selectively ignore the work submitted to CCAMP. In either case I don't think this should be blamed on the folks who's (individually) submitted the work to IETF as individuals who are full-fledged members of the IETF community... Zhi -----Original Message----- From: David Charlap [mailto: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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:11:58 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29928 for ; Sat, 25 Jan 2003 19:11:58 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FAD16222; Sat, 25 Jan 2003 16:15:10 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGW5D02101 for ; Thu, 23 Jan 2003 08:32:05 -0800 (PST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGW4b11758; Thu, 23 Jan 2003 08:32:04 -0800 (PST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NGW2s15534; Thu, 23 Jan 2003 11:32:03 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 11:32:02 -0500 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 11:31:59 -0500 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:11:59 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29937 for ; Sat, 25 Jan 2003 19:11:58 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FKD16533; Sat, 25 Jan 2003 16:15:20 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH1XD18419 for ; Thu, 23 Jan 2003 09:01:33 -0800 (PST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH1Wb27167; Thu, 23 Jan 2003 09:01:32 -0800 (PST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NH1Od27888; Thu, 23 Jan 2003 12:01:24 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 18:01:23 +0100 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)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 18:01:15 +0100 David You wrote: > In other words, these groups seem to want to forcibly change > RSVP into a protocol that more closely resembles some other > protocol that they're more intimately familiar with. My recollection of history brings me to a little paraphrasing of your statement: - In other words, the IETF seemed to want to forcibly change - transport networking into a thing that more closely resembles - some other network that they're more intimately familiar with. If you agree, let's than put the pots and the kettles where they belong and join forces on a constructive way forward. That is in our common interest. Leen Mak. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:00 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29967 for ; Sat, 25 Jan 2003 19:12:00 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FOD16552; Sat, 25 Jan 2003 16:15:24 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH1pD18460 for ; Thu, 23 Jan 2003 09:01:51 -0800 (PST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH1nb27583; Thu, 23 Jan 2003 09:01:49 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA07278; Thu, 23 Jan 2003 12:01:00 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25572; Thu, 23 Jan 2003 12:01:00 -0500 (EST) Message-ID: <3E301FF1.8080605@marconi.com> From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he 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 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 12:01:37 -0500 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:11:57 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29925 for ; Sat, 25 Jan 2003 19:11:56 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FHD16514; Sat, 25 Jan 2003 16:15:17 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGnWD10769 for ; Thu, 23 Jan 2003 08:49:32 -0800 (PST) Received: from w2ksjexg01.ciena.com ([12.7.169.25]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NGnVb20017; Thu, 23 Jan 2003 08:49:31 -0800 (PST) Received: from wntcsdexg01.csd.ciena.com ([10.34.31.31]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C2BQNJYY; Thu, 23 Jan 2003 08:48:49 -0800 Received: by webdev-llnt.oni.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 08:49:02 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 08:48:53 -0800 Folks, Keep in mind also that we are talking about the application of RSVP to switched transport networks (i.e., SDH), not to IP networks directly. This is the scope of the ITU specification that would use these extensions. Cheers, Lyndon Ong _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:12 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29992 for ; Sat, 25 Jan 2003 19:12:12 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0F6D16124; Sat, 25 Jan 2003 16:15:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NG71D23120 for ; Thu, 23 Jan 2003 08:07:01 -0800 (PST) Received: from mailserv.hatterasnetworks.com (mailserv.hatterasnetworks.com [63.89.58.4]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NG6xb00476; Thu, 23 Jan 2003 08:06:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> Thread-Topic: IANA Considerations for RSVP Thread-Index: AcLC+OcbwxgKzZ6bT1yvaa9ntdugvgAAEKRg From: "Brian Hassink" To: "David Charlap" , "Bob Braden" Cc: , , , , , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gamma.isi.edu id h0NG71D23120 Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 11:06:53 -0500 Content-Transfer-Encoding: 8bit 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: > > 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:13 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00004 for ; Sat, 25 Jan 2003 19:12:13 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FWD16643; Sat, 25 Jan 2003 16:15:32 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH9tD23139 for ; Thu, 23 Jan 2003 09:09:55 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH9sb03953; Thu, 23 Jan 2003 09:09:54 -0800 (PST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0NH9aB6005977; Thu, 23 Jan 2003 09:09:36 -0800 (PST) Received: from cisco.com (sjc-vpn2-769.cisco.com [10.21.115.1]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADS98103; Thu, 23 Jan 2003 08:58:53 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Jan 2003 12:09:36 -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 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 References: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> User-Agent: Mutt/1.4i Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 12:09:35 -0500 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. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:16 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00024 for ; Sat, 25 Jan 2003 19:12:15 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FeD16696; Sat, 25 Jan 2003 16:15:40 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHSkD03718 for ; Thu, 23 Jan 2003 09:28:46 -0800 (PST) Received: from host19.ipowerweb.com (host19.ipowerweb.com [12.129.206.119]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHSjb13720; Thu, 23 Jan 2003 09:28:45 -0800 (PST) Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.128.219.249] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 18bl8x-0007Zi-00; Thu, 23 Jan 2003 09:27:59 -0800 Message-ID: <3E30260A.82698500@GraIyMage.com> From: Eric Gray Reply-To: GraIyMag@GraIyMage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 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 References: <200301222140.VAA00937@gra.isi.edu> <3E301086.3000002@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - isi.edu X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 12:27:38 -0500 Content-Transfer-Encoding: 7bit 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. 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:18 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00038 for ; Sat, 25 Jan 2003 19:12:17 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FSD16615; Sat, 25 Jan 2003 16:15:28 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH6RD20648 for ; Thu, 23 Jan 2003 09:06:27 -0800 (PST) Received: from fed1mtao06.cox.net (fed1mtao06.cox.net [68.6.19.125]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NH6Qb01942; Thu, 23 Jan 2003 09:06:26 -0800 (PST) Received: from ieee.org ([68.6.114.234]) by fed1mtao06.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030123170618.JTSS3243.fed1mtao06.cox.net@ieee.org>; Thu, 23 Jan 2003 12:06:18 -0500 Message-ID: <3E302109.1010200@ieee.org> 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 X-Accept-Language: en-us, en MIME-Version: 1.0 To: braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Rsvp] [Fwd: Re: IANA Considerations for RSVP] Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 09:06:17 -0800 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 ----- > > > > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:20 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00052 for ; Sat, 25 Jan 2003 19:12:20 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FiD16736; Sat, 25 Jan 2003 16:15:44 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHhlD08507 for ; Thu, 23 Jan 2003 09:43:47 -0800 (PST) Received: from host19.ipowerweb.com (host19.ipowerweb.com [12.129.206.119]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHhkb21830; Thu, 23 Jan 2003 09:43:46 -0800 (PST) Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.128.219.249] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 18blNR-0002jY-00; Thu, 23 Jan 2003 09:42:57 -0800 Message-ID: <3E30298A.881E59C3@GraIyMage.com> From: Eric Gray Reply-To: GraIyMag@GraIyMage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 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 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - isi.edu X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 12:42:34 -0500 Content-Transfer-Encoding: 7bit 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... > ... _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:21 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00055 for ; Sat, 25 Jan 2003 19:12:20 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FaD16668; Sat, 25 Jan 2003 16:15:36 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHLbD29279 for ; Thu, 23 Jan 2003 09:21:37 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHLab10012; Thu, 23 Jan 2003 09:21:36 -0800 (PST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NHLU928844; Thu, 23 Jan 2003 12:21:30 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [135.248.252.19]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA13652; Thu, 23 Jan 2003 11:21:22 -0600 (CST) Message-ID: <3E30248B.980C42B2@lucent.com> From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh 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 References: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> <3E301519.4010807@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 10:21:15 -0700 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:25 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00080 for ; Sat, 25 Jan 2003 19:12:24 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FmD16761; Sat, 25 Jan 2003 16:15:48 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHqND13275 for ; Thu, 23 Jan 2003 09:52:23 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHqMb28856; Thu, 23 Jan 2003 09:52:22 -0800 (PST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NHqL915229; Thu, 23 Jan 2003 12:52:21 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 12:52:20 -0500 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 12:52:17 -0500 Hi Eric, Please see Steve's email on the history. After reading that, I hope you would change your mind about the "fait accompli" remark... Thanks Zhi -----Original Message----- From: Eric Gray [mailto: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... > ... _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:29 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00094 for ; Sat, 25 Jan 2003 19:12:29 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FqD16788; Sat, 25 Jan 2003 16:15:52 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIrHD17062 for ; Thu, 23 Jan 2003 10:53:17 -0800 (PST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NIrHb03984; Thu, 23 Jan 2003 10:53:17 -0800 (PST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIqUS66565; Thu, 23 Jan 2003 10:52:30 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIqUh84231; Thu, 23 Jan 2003 10:52:30 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: "Lin, Zhi-Wei (Zhi)" cc: David Charlap , Bob Braden , , , , , , , In-Reply-To: Message-ID: <20030123104246.W83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 10:52:30 -0800 (PST) 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. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:34 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00108 for ; Sat, 25 Jan 2003 19:12:33 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0FuD16812; Sat, 25 Jan 2003 16:15:56 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJ4SD23642 for ; Thu, 23 Jan 2003 11:04:28 -0800 (PST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJ4Rb09697; Thu, 23 Jan 2003 11:04:27 -0800 (PST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NJ4L327664; Thu, 23 Jan 2003 14:04:21 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 14:04:21 -0500 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 14:04:20 -0500 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. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:36 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00122 for ; Sat, 25 Jan 2003 19:12:35 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0G0D16852; Sat, 25 Jan 2003 16:16:00 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJ8FD25099 for ; Thu, 23 Jan 2003 11:08:15 -0800 (PST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJ8Eb11347; Thu, 23 Jan 2003 11:08:14 -0800 (PST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NJ8C329981; Thu, 23 Jan 2003 14:08:12 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 14:08:12 -0500 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 14:08:09 -0500 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. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:40 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00140 for ; Sat, 25 Jan 2003 19:12:39 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0G4D16878; Sat, 25 Jan 2003 16:16:04 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJLDD01865 for ; Thu, 23 Jan 2003 11:21:13 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJLBb18459; Thu, 23 Jan 2003 11:21:11 -0800 (PST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NJKOi20587; Thu, 23 Jan 2003 14:20:24 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.58.32]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA18520; Thu, 23 Jan 2003 14:20:22 -0500 (EST) Message-ID: <3E304076.D5AF0CAF@lucent.com> From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en 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 References: <20030123104246.W83975-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 14:20:22 -0500 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:47 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00160 for ; Sat, 25 Jan 2003 19:12:46 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0G8D16938; Sat, 25 Jan 2003 16:16:08 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJVcD07508 for ; Thu, 23 Jan 2003 11:31:38 -0800 (PST) Received: from lightwave.chromisys.com (lightwave.chromisys.com [63.102.55.206]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NJVbb23816; Thu, 23 Jan 2003 11:31:37 -0800 (PST) Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZ1WMA>; Thu, 23 Jan 2003 11:31:32 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 11:31:30 -0800 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:12:56 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00175 for ; Sat, 25 Jan 2003 19:12:55 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0GDD16983; Sat, 25 Jan 2003 16:16:13 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NNQCD25449 for ; Thu, 23 Jan 2003 15:26:12 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0NNQBb08620; Thu, 23 Jan 2003 15:26:11 -0800 (PST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NNQ4705876; Thu, 23 Jan 2003 18:26:04 -0500 (EST) Received: from lucent.com ([135.248.116.65]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA02764; Thu, 23 Jan 2003 17:25:57 -0600 (CST) Message-ID: <3E3079AF.3010ED7C@lucent.com> From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh 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 References: <9D42C6E086250248810DCADA39CE7EFC97217E@nimbus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 16:24:31 -0700 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:24:14 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00297 for ; Sat, 25 Jan 2003 19:24:10 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0K6D18187; Sat, 25 Jan 2003 16:20:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0O0O6D25692 for ; Thu, 23 Jan 2003 16:24:06 -0800 (PST) Received: from alpha2.tellium.com ([65.125.55.125]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0O0O4b05353; Thu, 23 Jan 2003 16:24:05 -0800 (PST) Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 19:19:40 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 12:03:29 -0500 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 12:03:26 -0500 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 > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:24:21 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00311 for ; Sat, 25 Jan 2003 19:24:21 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0KED18300; Sat, 25 Jan 2003 16:20:14 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0O0RJD26507 for ; Thu, 23 Jan 2003 16:27:19 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0O0RIb06728; Thu, 23 Jan 2003 16:27:18 -0800 (PST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O0QxSQ029809; Thu, 23 Jan 2003 16:26:59 -0800 (PST) Received: from cisco.com (sjc-vpn2-370.cisco.com [10.21.113.114]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADT31976; Thu, 23 Jan 2003 16:16:11 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); 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 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 References: <9D42C6E086250248810DCADA39CE7EFC97217E@nimbus> <3E3079AF.3010ED7C@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E3079AF.3010ED7C@lucent.com> User-Agent: Mutt/1.4i Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 19:26:55 -0500 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:24:23 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00326 for ; Sat, 25 Jan 2003 19:24:22 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0KKD18473; Sat, 25 Jan 2003 16:20:20 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0O1D2D15971 for ; Thu, 23 Jan 2003 17:13:02 -0800 (PST) Received: from lightwave.chromisys.com (lightwave.chromisys.com [63.102.55.206]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0O1D0b25873; Thu, 23 Jan 2003 17:13:01 -0800 (PST) Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZ1XFM>; Thu, 23 Jan 2003 17:12:55 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Thu, 23 Jan 2003 17:12:46 -0800 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 > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:24:30 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00340 for ; Sat, 25 Jan 2003 19:24:29 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0KRD18641; Sat, 25 Jan 2003 16:20:27 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0O7nUD04119 for ; Thu, 23 Jan 2003 23:49:34 -0800 (PST) Received: from mail.alcatel.be (alc239.alcatel.be [195.207.101.239]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0O7nOb02759; Thu, 23 Jan 2003 23:49:24 -0800 (PST) Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0O7mpS04014; Fri, 24 Jan 2003 08:48:51 +0100 (MET) Received: from alcatel.be ([149.204.0.178]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003012408484820:1037 ; Fri, 24 Jan 2003 08:48:48 +0100 Message-ID: <3E30EFBB.6A3A90AF@alcatel.be> From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en 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 References: <05707214338CD5119BFF0040A5B170D302889721@mail3.tellium.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 08:48:49, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 08:48:58, Serialize complete at 01/24/2003 08:48:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 08:48:11 +0100 Content-Transfer-Encoding: 7bit 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 From rsvp-admin@mailman.isi.edu Sat Jan 25 19:24:37 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00354 for ; Sat, 25 Jan 2003 19:24:36 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0KWD18704; Sat, 25 Jan 2003 16:20:32 -0800 (PST) Received: from alpha2.tellium.com ([65.125.55.125]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OFntD11744 for ; Fri, 24 Jan 2003 07:49:55 -0800 (PST) Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Jan 2003 10:48:32 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 10:47:19 -0500 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 10:47:16 -0500 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 > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:24:48 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00368 for ; Sat, 25 Jan 2003 19:24:47 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0KbD18728; Sat, 25 Jan 2003 16:20:37 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OGOVD23507 for ; Fri, 24 Jan 2003 08:24:32 -0800 (PST) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0OGOUb01700 for ; Fri, 24 Jan 2003 08:24:30 -0800 (PST) Message-ID: From: Jeff Parker To: "'Bala Rajagopalan'" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 11:24:11 -0500 > Going forward, I hope the IETF makes it mandatory > to have outside work examined in the relevant WGs with > the same seriousness as regular WG items (or assign > evaluation teams, like design teams). > > Bala Rajagopalan Given that much of the work done at the IETF is done by volunteers, this bar may not be as high as it seems. I see Last Calls on WG items in a number of groups that elicit little or no comment. It is certainly worth the effort to try to make cooperation between IETF and other bodies easier. But unfunded mandates are difficult to staff. - jeff parker _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Sat Jan 25 19:24:49 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00381 for ; Sat, 25 Jan 2003 19:24:49 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0Q0KhD18772; Sat, 25 Jan 2003 16:20:43 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0OGkmD04242 for ; Fri, 24 Jan 2003 08:46:48 -0800 (PST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0OGkjb13069 for ; Fri, 24 Jan 2003 08:46:45 -0800 (PST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0OGked06632; Fri, 24 Jan 2003 11:46:40 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [135.248.252.10]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA27992; Fri, 24 Jan 2003 10:46:36 -0600 (CST) Message-ID: <3E316DE3.2DFBA173@lucent.com> From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Bala Rajagopalan CC: "'Dimitri.Papadimitriou@alcatel.be'" , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET References: <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Fri, 24 Jan 2003 09:46:27 -0700 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 > > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Mon Jan 27 08:12:32 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15056 for ; Mon, 27 Jan 2003 08:12:31 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RDFqD14596; Mon, 27 Jan 2003 05:15:52 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0R4ExD27350 for ; Sun, 26 Jan 2003 20:14:59 -0800 (PST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4EtU25153; Sun, 26 Jan 2003 20:14:55 -0800 (PST) From: Bob Braden Message-Id: <200301270414.h0R4EtU25153@boreas.isi.edu> To: braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, jplang@ieee.org Subject: Re: [Rsvp] [Fwd: Re: IANA Considerations for RSVP] X-Sun-Charset: US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sun, 26 Jan 2003 20:14:55 -0800 (PST) *> *> 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Mon Jan 27 08:12:36 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15070 for ; Mon, 27 Jan 2003 08:12:36 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RDFxD14636; Mon, 27 Jan 2003 05:15:59 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0R4N5D28644 for ; Sun, 26 Jan 2003 20:23:05 -0800 (PST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4N0s28487; Sun, 26 Jan 2003 20:23:00 -0800 (PST) From: Bob Braden Message-Id: <200301270423.h0R4N0s28487@boreas.isi.edu> 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 X-Sun-Charset: US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sun, 26 Jan 2003 20:23:00 -0800 (PST) David, I would like to mention that I thoroughly support all you have been saying in this thread -- and you have been saying it forcefully and well. Bob Braden _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Mon Jan 27 08:12:50 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15084 for ; Mon, 27 Jan 2003 08:12:49 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RDGBD14687; Mon, 27 Jan 2003 05:16:11 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0R4dDD01421 for ; Sun, 26 Jan 2003 20:39:13 -0800 (PST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4d7Y06027; Sun, 26 Jan 2003 20:39:07 -0800 (PST) From: Bob Braden Message-Id: <200301270439.h0R4d7Y06027@boreas.isi.edu> 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 X-Sun-Charset: US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sun, 26 Jan 2003 20:39:07 -0800 (PST) Friends, In trying to sort out how we should have handled RSVP_TE and all its offspring, it is instructive to read RFC 2814 that describes the Subnet Bandwidth Manager (SBM). Like RSVP-TE and its offspring, the SBM was an RSVP-like protocol for signaling at the link layer. It is carefully documented as a distinct protocol, alhtough in fact there are RSVP extensions for the SBM. It leaves RSVP as a network- (i.e., Internet-)layer protocol, as it was originally designed. I believe using the SBM approach for RSVP-TE would have avoided some of the problems we are seeing today. To imply, as I often see done, that RSVP-TE is "just RSVP with a few extensions" was and is dishonest. Its semantics are fundamentally different in important ways, even if the syntax is the same. There is more to protocols than bit and byte formats. Do we need to have this discussion of 3 large mailing lists? Bob Braden _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Mon Jan 27 08:12:56 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15099 for ; Mon, 27 Jan 2003 08:12:55 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RDGJD14709; Mon, 27 Jan 2003 05:16:19 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0R4pkD03760 for ; Sun, 26 Jan 2003 20:51:46 -0800 (PST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4j4Q08602; Sun, 26 Jan 2003 20:45:04 -0800 (PST) From: Bob Braden Message-Id: <200301270445.h0R4j4Q08602@boreas.isi.edu> 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 X-Sun-Charset: US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sun, 26 Jan 2003 20:45:04 -0800 (PST) *> *> Going forward, I hope the IETF makes it mandatory *> to have outside work examined in the relevant WGs with *> the same seriousness as regular WG items (or assign *> evaluation teams, like design teams). This would bring *> overall sanity and be beneficial for all groups. *> This is one good choice -- the other is to clearly fence off the non-IETF extensions with a surgeon general's warning. Bob Braden *> regards, *> *> *> Bala Rajagopalan *> Tellium, Inc. *> 2 Crescent Pl. *> Ocean Port, NJ 07757 *> USA *> Ph: +1-732-923-4237 *> Email: 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 *> _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Mon Jan 27 11:29:14 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18819 for ; Mon, 27 Jan 2003 11:29:13 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RGP8D04302; Mon, 27 Jan 2003 08:25:08 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RGO4D04046 for ; Mon, 27 Jan 2003 08:24:04 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0RGO2b21826; Mon, 27 Jan 2003 08:24:02 -0800 (PST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h0RGNr009087; Mon, 27 Jan 2003 17:23:53 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h0RGNpN28319; Mon, 27 Jan 2003 17:23:51 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 17:23:50 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C877C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'lindell@ISI.EDU'" Cc: "'Bob Braden'" , "'rsvp@ISI.EDU'" , "'hemanth_khare@rediffmail.com'" , "'schultz@io.iol.unh.edu'" Subject: RE: [Rsvp] RE: doubt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Mon, 27 Jan 2003 17:23:49 +0100 hi > > my personal opinion: the policy objects tried to repair the > missing key > > management to some extend (i.e. they provide the user > identity for the > > purpose of policy based admission control). > > No. Policy and hop-by-hop integrity perform complementary functions. if you use kerberos within the policy object then you can use the session key for the integrity object to protect the messages. hence there is a relationship between the two. without a policy object would still have to provide an authentication and key exchange protocol to establish the key (if not manually established). if you look at the following figure which shows a typical end-to-end signaling scenario. +------------------+ +---------------+ +------------------+ | | | | | | | Administrative | | Intermediate | | Administrative | | Domain A | | Domains | | Domain B | | | | | | | | (Inter-domain Communication) | | +---------+---+---------------+---+---------+ | | (Intra-domain | | | | (Intra-domain | | Communication) | | | | Communication) | | | | | | | | | | | | | | | | | +--------+---------+ +---------------+ +---------+--------+ ^ v | | First Peer Communication Last Peer Communication | | +-----+-----+ +-----+-----+ | RSVP | | RSVP | | Node A | | Node B | +-----------+ +-----------+ if you assume that charging of the qos reservation is done in a peer-to-peer fashion then the RSVP Node A would be charged by domain A and then each domain charges its peering domain. (charging for the data sender) hence domain A would require some form of user authentication to perform credit check functionality. it is likely that the first router would be rsvp capable. additionally you need to protect the signaling messages (integrity, replay, etc. protection). especially in a mobile scenario you do not have a pre-established key with the first rsvp router. this leads me to the conclusion that you need a key exchange protocol which establishes a security association which then serves to protect the rsvp signaling messages. it would not make sense to perform user authentication at other routers in the same administrative domain. i wouldn't even know a reason why you would like to do that. you wouldn't want to authenticate the signaling initiator to intermediate networks along the path. this would effectively cause some other problems - additionally this is a major shift in the charging model. i once looked at the kerberos / rsvp description of windows 2000 and i had the impression that they used the policy data object to provide the key for the integrity object. > > Hop-by-hop integrity authenticates that the message came from > a trusted > neighboring router in the signaling path and that the contents have > not been modified in-route. i agree that the integrity object allows you to protect the signaling messages. if you have this configuration: RSVP router X ------> non-RSVP router A ----------> RSVP router Y then the rsvp integrity object would disallow the non-RSVP router A to modify, replay, inject, etc. an RSVP message to the RSVP aware router Y. this, however, assumes that you have one or more non-rsvp routers between rsvp aware routers along the path. this leads us back to our previous discussion. > > Policy identifies the sender of the request and is the basis for > policy based admission control and charging. A sender gets > charged for a request, not an intermediate router in the signaling > path. this is very true. i will send you a document describing two different charging models (once we have finished it). one charging model is based on peering-relationships between networks. the other one allows intermediate administrative domains to charge the end host/initiator directly. i (or better we) would like to see your opinion. > > > > > the hop-by-hop security is perfectly fine for the charging > model currently > > used in the internet. i will send around a document giving > detailed reason > > s > > for this statement in the near future. > > No. See above. ciao hannes > > Bob > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Mon Jan 27 17:19:13 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29042 for ; Mon, 27 Jan 2003 17:19:13 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMFAD02057; Mon, 27 Jan 2003 14:15:10 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMDtD01205 for ; Mon, 27 Jan 2003 14:13:55 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMDlb25678; Mon, 27 Jan 2003 14:13:47 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA03652; Mon, 27 Jan 2003 22:13:47 GMT Message-Id: <200301272213.WAA03652@gra.isi.edu> 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 X-Sun-Charset: US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Mon, 27 Jan 2003 22:13:47 GMT *> *> *> Friends, *> *> In trying to sort out how we should have handled RSVP_TE and all its *> offspring, it is instructive to read RFC 2814 that describes the *> Subnet Bandwidth Manager (SBM). Like RSVP-TE and its offspring, I apologize for a misstatement here; I should not have singled out RSVP-TE for abuse. In fact, there are at least two or three distinct flavors of RSVP offspring: RSVP-TE for MPLS setup, the OIF folks who have an RSVP-like protocol for link-layer signaling at the UNI, and maybe the ATM folks. (I assume the GMPLS folks fall into the RSVP-TE camp.) The same comment about SBM applies equally to all these "illegitimate offspring" of RSVP. (They are each fine upstanding protocols in their own right, no doubt; it is only their parentage that is shady.) Bob Braden *> the SBM was an RSVP-like protocol for signaling at the link layer. *> It is carefully documented as a distinct protocol, alhtough in *> fact there are RSVP extensions for the SBM. It leaves RSVP as *> a network- (i.e., Internet-)layer protocol, as it was originally *> designed. *> *> I believe using the SBM approach for RSVP-TE would have avoided some of *> the problems we are seeing today. To imply, as I often see done, that *> RSVP-TE is "just RSVP with a few extensions" was and is dishonest. Its *> semantics are fundamentally different in important ways, even if the *> syntax is the same. There is more to protocols than bit and byte *> formats. *> *> Do we need to have this discussion of 3 large mailing lists? *> *> Bob Braden *> _______________________________________________ *> Rsvp mailing list *> Rsvp@mailman.isi.edu *> http://mailman.isi.edu/mailman/listinfo/rsvp *> _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Jan 28 08:21:00 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25360 for ; Tue, 28 Jan 2003 08:20:59 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0SDFSD02482; Tue, 28 Jan 2003 05:15:28 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RK8GD07549 for ; Mon, 27 Jan 2003 12:08:18 -0800 (PST) Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0RK8Eb18261 for ; Mon, 27 Jan 2003 12:08:15 -0800 (PST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA16128; Mon, 27 Jan 2003 15:04:11 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) 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 Reply-To: curtis@fictitious.org In-reply-to: Your message of "Fri, 24 Jan 2003 10:47:16 EST." <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com> From: Curtis Villamizar Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Mon, 27 Jan 2003 15:04:11 -0500 In message <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com>, Bala R 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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Jan 28 08:21:21 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25384 for ; Tue, 28 Jan 2003 08:21:21 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0SDFbD02520; Tue, 28 Jan 2003 05:15:37 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMiiD19830 for ; Mon, 27 Jan 2003 14:44:44 -0800 (PST) Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMifb17327; Mon, 27 Jan 2003 14:44:41 -0800 (PST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA17537; Mon, 27 Jan 2003 17:40:58 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301272240.RAA17537@workhorse.fictitious.org> 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 Reply-To: curtis@fictitious.org In-reply-to: Your message of "Thu, 23 Jan 2003 16:24:31 MST." <3E3079AF.3010ED7C@lucent.com> From: Curtis Villamizar Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Mon, 27 Jan 2003 17:40:58 -0500 In message <3E3079AF.3010ED7C@lucent.com>, Stephen Trowbridge writes: > 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 Please take careful note of the last sentence. 3.2.2 ITU-T Recognition at ISOC/IETF ITU-T Study Group Chairmen can authorize one or more members to attend an IETF meeting as an official ITU-T delegate speaking authoritatively on behalf of the activities of the Study Group (or a particular Rapporteur Group). The Study Group Chairman sends the ITU-T list of delegates by email to the Working Group chair, with a copy to the Area Directors, and also to the Study Group. Note that, according to IETF process, opinions expressed by any such delegate are given equal weight with opinions expressed by other working group participants. If Sun Microsystems or Microsoft sends someone to authoritatively speak on behalf of a protocol that is documented but otherwise entirely under control of that entity, an IETF may consider documenting its existance in an "informational" document. The same applies to ITU-T sending someone to authoritatively speak on behalf of their work. Any such document is considered to be encumbered by intellectual property restrictions and therefore is treated appropriately. An IESG may consent documenting the existance of an outside effort and IETF WGs are still free to completely ignore it. This may be the case with ASON and other ITU-T requirements documents where the ITU-T has stated some requirements and where the IETF may choose to document the existance of the ITU-T requirements but is free to ignore any or all of them. Part of the reason for the turf (not really jurisdictional) issue is the overlap that occurs when considering TDM over MPLS or IP. A fundamental difference in the way the ITU-T and IETF think about this is the ITU-T sees this as a new layer under the TDM network and the IETF sees this as a means to support legacy TDM service. As with the IP QoS topic of the mid-1990s, what matters is what the providers want to do with their networks and what proves profitable to do. If the view that TDM over MPLS just serves to accommodate a declining TDM customer base proves accurate, then the IETF would be wise to ignore much of what the ITU-T is doing in this area. Back to the original question posed by Bod Braden. It might be possible for IANA or the RSVP experts (Bob) to go to a WG for a recommendation on any given request. Since RSVP is highly extensible the WG could make a recommendation that a code point for an object be added but that the WG's concensus is that the protocol is of no interest to the IETF. As long as code point space is plentiful a portion of the number space could be set aside for such allocations. [This may be the same as Bob'd Surgeon General's warning idea.] Curtis > 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. Rathe > r > > 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 tha > t > > 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 > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Jan 28 08:21:22 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25387 for ; Tue, 28 Jan 2003 08:21:22 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0SDFgD02539; Tue, 28 Jan 2003 05:15:42 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMj7D20141 for ; Mon, 27 Jan 2003 14:45:07 -0800 (PST) Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMj5b17669 for ; Mon, 27 Jan 2003 14:45:06 -0800 (PST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA17542; Mon, 27 Jan 2003 17:41:33 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301272241.RAA17542@workhorse.fictitious.org> To: Bala Rajagopalan cc: "'curtis@fictitious.org'" , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org In-reply-to: Your message of "Mon, 27 Jan 2003 15:29:46 EST." <05707214338CD5119BFF0040A5B170D30288973A@mail3.tellium.com> From: Curtis Villamizar Subject: [Rsvp] Re: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Mon, 27 Jan 2003 17:41:33 -0500 In message <05707214338CD5119BFF0040A5B170D30288973A@mail3.tellium.com>, Bala R ajagopalan writes: > > > > -----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 Uninteresting in this context usually means that there is no consensus on any good reason for a particular protocol extension to exist or that there is sufficient concensus that the protocol extension represents a poorly engineered solution. Its just when you ask for codepoints for "uninteresting" work that there is trouble. The IETF should not feel obligated to accommodate a study group coming to it that is trying to jam a square peg into a round hole. Curtis _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Jan 28 08:21:27 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25413 for ; Tue, 28 Jan 2003 08:21:26 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0SDFXD02501; Tue, 28 Jan 2003 05:15:33 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RKZrD19138 for ; Mon, 27 Jan 2003 12:35:54 -0800 (PST) Received: from alpha2.tellium.com ([65.125.55.125]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0RKZrb04452 for ; Mon, 27 Jan 2003 12:35:53 -0800 (PST) Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 15:31:23 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 15:29:50 -0500 Message-ID: <05707214338CD5119BFF0040A5B170D30288973A@mail3.tellium.com> From: Bala Rajagopalan To: "'curtis@fictitious.org'" Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Rsvp] RE: IANA Considerations for RSVP Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Mon, 27 Jan 2003 15:29:46 -0500 > -----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 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Jan 28 08:21:31 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25428 for ; Tue, 28 Jan 2003 08:21:31 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0SDFOD02461; Tue, 28 Jan 2003 05:15:24 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0R4AmD26901 for ; Sun, 26 Jan 2003 20:10:48 -0800 (PST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4AcU23818; Sun, 26 Jan 2003 20:10:38 -0800 (PST) From: Bob Braden Message-Id: <200301270410.h0R4AcU23818@boreas.isi.edu> 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 X-Sun-Charset: US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sun, 26 Jan 2003 20:10:38 -0800 (PST) *> David *> *> You wrote: *> *> > In other words, these groups seem to want to forcibly change *> > RSVP into a protocol that more closely resembles some other *> > protocol that they're more intimately familiar with. *> *> My recollection of history brings me to a little paraphrasing of *> your statement: *> *> - In other words, the IETF seemed to want to forcibly change *> - transport networking into a thing that more closely resembles Sorry, I am unfamiliar with the term "transport networking". Could you explain it please? Thanks, Bob Braden *> - some other network that they're more intimately familiar with. *> *> If you agree, let's than put the pots and the kettles where they *> belong and join forces on a constructive way forward. That is *> in our common interest. *> *> Leen Mak. *> *> *> _______________________________________________ *> Rsvp mailing list *> Rsvp@mailman.isi.edu *> http://mailman.isi.edu/mailman/listinfo/rsvp *> _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Jan 28 09:13:00 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25359 for ; Tue, 28 Jan 2003 08:20:58 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0SDFlD02561; Tue, 28 Jan 2003 05:15:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0R4HVD27937 for ; Sun, 26 Jan 2003 20:17:31 -0800 (PST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4HQs26211; Sun, 26 Jan 2003 20:17:26 -0800 (PST) From: Bob Braden Message-Id: <200301270417.h0R4HQs26211@boreas.isi.edu> 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 X-Sun-Charset: US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sun, 26 Jan 2003 20:17:26 -0800 (PST) *> *> On Thu, Jan 23, 2003 11:06:53AM -0500, Brian Hassink allegedly wrote: *> > Didn't the IETF set the precedent by extending RSVP from an IntServ *> > protocol to an MPLS protocol? *> *> Check the documentation. RSVP is not an intserv protocol. It's *> (potentially) used by intserv. It's also used for other things. *> _______________________________________________ Scott, Weeellll, RSVP *was* designed as the signaling protocol for int-serv. Since we believe that generality and extensibility are Good Things, we made it general and extensible. (Again, perhaps a mistake, in retrospect ... ;-( ) Bob _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp