From owner-rap@ops.ietf.org Fri Apr 5 21:28:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17889 for ; Fri, 5 Apr 2002 21:28:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tfuZ-0009XJ-00 for rap-data@psg.com; Fri, 05 Apr 2002 18:26:39 -0800 Received: from rwcrmhc53.attbi.com ([204.127.198.39]) by psg.com with esmtp (Exim 3.35 #1) id 16tfuZ-0009XD-00 for rap@ops.ietf.org; Fri, 05 Apr 2002 18:26:39 -0800 Received: from study ([24.61.240.100]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020406022637.EQCF21252.rwcrmhc53.attbi.com@study>; Sat, 6 Apr 2002 02:26:37 +0000 Message-ID: <009801c1dd11$a70fd620$650a0a0a@ne.client2.attbi.com> From: "Walter Weiss" To: "John Schnizlein" Cc: , "DiffServ2" , References: <4.3.2.7.2.20020327164457.019cd2a8@diablo.cisco.com> Subject: Re: [Diffserv] Re: why i should like pibs Date: Fri, 5 Apr 2002 21:20:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John, Sorry for the late reply. I missed your posting. Comments follow inline. regards, -Walter ---------- [snip] > The fundamental problem with distributing policy to traffic-forwarding > devices rather than translating policy into configurations under the > constraints of the composition (topology) and capabilities of the > devices in the path of the traffic remains. It is essentially wishful > thinking that individual devices can determine the correct configuration > of their local parameters without the domain-wide information. I have > not been persuaded that the capability-exchange between the PEP and PDP > solves this problem. There are hints of importance of the domain-wide > context in DiffServ's per-domain behavior (PDB) specifications. > I can't speak for others but the capabilities aspects of COPS-PR have always troubled me although for slightly different reasons. It is my view that capabilities are abstractions of implementations. However, it is difficult to decide where to stop. It is fine to say that a router supports classification. But it is not that simple. A policy server (and I use the term very loosely :) would also like to know how many classifiers, whether ranges or lists are supported, and where classifiers can be placed in a datapath. There is far more complexity in representing capabilities than it appears. Therefore, my view of capabilities is that it is a convenient mechanism not for identifying the implementation, but for defining the hardware and software versioning that allows a policy server to implicitly know what configuration will and won't work. > It is even a mistake IMHO to invite network administrators to establish > policies their networks cannot deliver. Although consensus was never > reached on the architecture for policy networking, the insistence that > policy be independent of the devices and topology that started there > seems to persist under the surface of the COPS-PR development. > Since policies within the context of COPS-PR are specific to a given device, clearly the implication that COPS-PR provides network level policy functionality is erroneous. > My concerns about distributing un-interpreted policy appears to be > shared by the network operators who shared their view with people > soliciting "requirements for network configuration" when they say > they do not want policy, or even configuration, distributed to devices > until they know what it will do to the network. > Given the scope of application I am offering (binding of edge resource consumers to specific services), I would suggest that core operators would be unaffected and unaware of these configurations. > Response to particular points: > > At 04:50 PM 3/26/2002, Walter Weiss wrote: [snip] > >I would also like to consider this issue from a requirements perspective. In > >my view, we can divide operational needs into four areas: Stats Collection, > >Events, Static config and Dynamic config. > > This taxonomy of operational needs for network management is novel. > Instead of the 5 FCAPS categories, it creates 4, with a new distinction > in configuration that may or may not have value. It also seems that > this Dynamic Config has a lot in common with what has been supported in > RADIUS as user profiles. Why is this not better treated as a QoS case > of authorization? > We had private discussions along similar lines at the last IETF meeting. The challenge has always been that the RADIUS protocol has serious limitations in it's ability to support edge provisioning issues (security, QoS, Tunnels, etc.) Conversely, COPS PIBs, while offering more sophisticated provisioning capabilities have not adequately addressed the authentication and access management issues. The AccessBind PIB makes some strides towards addressing this, but it is by no means comprehensive. > >I would also like to reconsider Bert's points. First, I would agree that the > >level of interest in COPS-PR is relatively small. However, I would argue > >that this is because Dynamic Config is only starting to become important as > >mappings for QoS, Security, and Tunneling are coming to the forefront. > > Maybe we should see if this new category of Dynamic Config really develops > before standardizing it into existence. > It already has. There is just no standard for it. There are lots of devices (CMTSes, GGSNs, and BRAS products) that are using COPS, SNMP, and RADIUS in proprietary ways to support the functionality I have described. The 3GPP have agreed on COPS-PR because they have this very need. This is not about whether the category exists but what the IETF will do (if anything) to provide a standard for supporting it. > >Second, I disagree that there is overlap with PIBs. While the DiffServ PIB > >and MIB are nearly identical, this was done because it was assumed that they > >were both addressing the config space that CLI is so clearly dominating. In > >the absense of a common model for all config, I believe this was a mistake. > > Don't follow this. You think any correspondence in the data models for the > DiffServ application is a mistake without a "common model for all config"? > Wouldn't incremental steps be more practical? > I actually favor incremental models over comprehensive models. Comprehensive models are really complicated and have to consider many factors. Data models (MIBs, PIBs, MOFs, Schemas, etc.) represent behavioral interfaces. If the behavioral requirements are different for different parts of the network, different technologies, and different implementations, the model quickly turns into an excercise in boiling the ocean. My point was that the MIB and PIB were conceived to address provisioning of the core of the DiffServ network. Given the clear domination of CLI in this space, the model is not ideally suited for edge config either. > >Given the unique applicability of COPS-PR, PIBs should be defined > >specifically for this purpose and only this purpose. > > Which unique applicability of COPS-PR is this? The newly proposed > Dynamic Config? > Correct. > >On Bert's third point, > >I would argue that the investment in PIBs is far smaller than he suggests. > >Given the specific scope of applicability, PIBs would not be appropriate for > >most IETF activities involving failure events or static config (routing, > >transport and applications). Hence, the number of PIBs is relatively small. > >Further, I do not believe that any of the alternatives on the table can meet > >these requirements to the extent that COPS-PR can. > > > >I would agree with Juergen that what we have today is a hodge-podge of > >protocols and mechanisms for configuration management and little incentive > >for changing the situation. As such, I see two alternatives: > >1. We can use COPS-PR and restrict it specifically to the area that it > >addresses most effectively: dynamic config management (at the network edge). > >2. We can block progress on all config drafts/standards to motivate a > >solution to Juergen's larger issue of concerted participation in a single > >and uniform set of standards. > > No one has proposed to "block progress on all config drafts/standards" > up until this point. Way back in the Configuration Management BOF in > Washington, I thought Bert supported Experimental status as the best > way to explore the new ideas proposed with COPS-PR and PIBs. > Yes and in that same discussion, it was also agreed that if PIBs were put on an experimental track, SNMPCONF MIBs would also be put on a experimental track. As long as we consider the larger question (config) rather than looking at a specific instance of the question (PIBs) I am fine with any answer. For me at least, the question is not what should be done with PIBs, but what should be done with config in general. When we have answered the second question the first one becomes easy. In the mean time all config related standards (Policy Framework, writable MIBs, and PIBs) should be treated consistently until we sort out the first question. > >We could also block the advancement of COPS-PR. However, that prevents us > >from addressing the dynamic config space and does not advance an > >alternative. > > Bert's original suggestion of Experimental seems again the best way to > encourage use of the new ideas in COPS-PR. I have never seen him (or > Randy, for that matter) try to "block advancement". I believe Randy at least is still considering his position on this. However, Bert should be able to offer a pretty clear position on whether he is in favor of Experimental or Informational (which to me amounts to blocked advancement). From owner-rap@ops.ietf.org Mon Apr 15 12:14:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22194 for ; Mon, 15 Apr 2002 12:14:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16x95g-000LmK-00 for rap-data@psg.com; Mon, 15 Apr 2002 09:12:28 -0700 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16x95e-000LmE-00 for rap@ops.ietf.org; Mon, 15 Apr 2002 09:12:26 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.38 2002/04/09 21:20:23 root Exp $) with ESMTP id g3FGBkv27162 for ; Mon, 15 Apr 2002 16:11:46 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.15 2002/04/01 17:51:48 root Exp $) with SMTP id g3FGApQ29040 for ; Mon, 15 Apr 2002 16:10:51 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041509112207328 ; Mon, 15 Apr 2002 09:11:22 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2XMFXLSD>; Mon, 15 Apr 2002 09:12:18 -0700 Message-ID: <65D5A07B5098D511BDDA0002A508E64F048E7792@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: RE: why i should like pibs Date: Mon, 15 Apr 2002 09:12:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk Randy, Here's a link to our open-source implementation of a client side SDK for COPS. This link should provide you with more information related to the usefulness of PIBs. The SDK also provides source code for a SPPI (RFC3159) compliant PIB Compiler/Client Control Interface Generator that integrates into the SDK. The SDK is at: http://www.intel.com/labs/manage/cops/ Hopefully, this demonstrates industry commitment to deliver quality and readily available tools for easy PIB development. Regards, Ravi -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, March 18, 2002 6:13 AM To: rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy From owner-rap@ops.ietf.org Fri Apr 19 07:25:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16161 for ; Fri, 19 Apr 2002 07:24:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16yWTx-000Lgm-00 for rap-data@psg.com; Fri, 19 Apr 2002 04:23:13 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16yWTw-000Lgg-00 for rap@ops.ietf.org; Fri, 19 Apr 2002 04:23:12 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16034; Fri, 19 Apr 2002 07:23:09 -0400 (EDT) Message-Id: <200204191123.HAA16034@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-tls-03.txt Date: Fri, 19 Apr 2002 07:23:09 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : COPS Over TLS Author(s) : J. Walker, A. Kulkarni Filename : draft-ietf-rap-cops-tls-03.txt Pages : 7 Date : 18-Apr-02 This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-cops-tls-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-cops-tls-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418141039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418141039.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Sun Apr 21 11:54:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27361 for ; Sun, 21 Apr 2002 11:54:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zJc6-000MdT-00 for rap-data@psg.com; Sun, 21 Apr 2002 08:50:54 -0700 Received: from [202.96.136.222] (helo=public.szptt.net.cn) by psg.com with smtp (Exim 3.36 #1) id 16zJc4-000MdK-00 for rap@ops.ietf.org; Sun, 21 Apr 2002 08:50:53 -0700 Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm183cc2f07c; Sun, 21 Apr 2002 15:50:29 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm203cc049df; Fri, 19 Apr 2002 15:47:27 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA26656 for ietf-123-outbound.01@ietf.org; Fri, 19 Apr 2002 09:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA25745 for ; Fri, 19 Apr 2002 07:23:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16034; Fri, 19 Apr 2002 07:23:09 -0400 (EDT) Message-Id: <200204191123.HAA16034@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-tls-03.txt Date: Fri, 19 Apr 2002 07:23:09 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : COPS Over TLS Author(s) : J. Walker, A. Kulkarni Filename : draft-ietf-rap-cops-tls-03.txt Pages : 7 Date : 18-Apr-02 This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-cops-tls-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-cops-tls-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418141039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418141039.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Mon Apr 22 13:06:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02904 for ; Mon, 22 Apr 2002 13:06:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zhDi-000K5b-00 for rap-data@psg.com; Mon, 22 Apr 2002 10:03:18 -0700 Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr) by psg.com with esmtp (Exim 3.36 #1) id 16zhDh-000K5S-00 for rap@ops.ietf.org; Mon, 22 Apr 2002 10:03:18 -0700 Received: from enst.fr (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id 198DE189A; Mon, 22 Apr 2002 19:03:15 +0200 (MEST) Message-ID: <3CC44326.E760711@enst.fr> Date: Mon, 22 Apr 2002 19:06:46 +0200 From: Nguyen Thi Mai Trang Organization: ENST - INFRES X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Cc: rap@ops.ietf.org Subject: SLA concept in Intserv/RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi everybody, I have a question about the notion of SLA (service level agreement) in Intserv/RSVP but I don't know where to post it because the group Intserv is no longer active. It seems that the notion SLA was born in Diffserv architecture. The SLA is necessary because network resources are statically provisioned. It's very clear. In Intserv/RSVP, I don't find the SLA/SLS (service level specification) concept in all concerning draft/RFCs . I wonder if there is no SLA/SLS concept in Intserv/RSVP, how we can make policy decision in Intserv/RSVP. Some clarifications: In Intserv/RSVP, client uses RSVP to request resource in the routers. The routers verify if it has sufficiently resources (Admission control) and the user has the right to request this amount of resource (Policy control) or not. If both are positives, it makes the resource reservation for this flow. My question is that if there is no SLA/SLS, how the network can answer (using COPS-RSVP for example) to the question "Does this client has the right to request such a reservation ?" ? Thank you very much, Mai Trang From owner-rap@ops.ietf.org Mon Apr 22 13:33:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04130 for ; Mon, 22 Apr 2002 13:33:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zhgn-000Ko1-00 for rap-data@psg.com; Mon, 22 Apr 2002 10:33:21 -0700 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.36 #1) id 16zhgm-000Knn-00 for rap@ops.ietf.org; Mon, 22 Apr 2002 10:33:20 -0700 Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GUZ00B01CPUIF@firewall.wcom.com> for rap@ops.ietf.org; Mon, 22 Apr 2002 17:32:18 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GUZ00B2NCPUAH@firewall.wcom.com>; Mon, 22 Apr 2002 17:32:18 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GUZ00B01CPT0R@dgismtp02.wcomnet.com>; Mon, 22 Apr 2002 17:32:17 +0000 (GMT) Received: from dgmexch08.wcomnet.com ([166.38.58.238]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GUZ002CYCPF6N@dgismtp02.wcomnet.com>; Mon, 22 Apr 2002 17:32:03 +0000 (GMT) Received: by DGMEXCH08.wcomnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 17:32:03 +0000 Content-return: allowed Date: Mon, 22 Apr 2002 17:31:54 +0000 From: "Rawlins, Diana" Subject: RE: SLA concept in Intserv/RSVP To: "'Nguyen Thi Mai Trang'" , ietf@ietf.org Cc: rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362EB09622@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; CHARSET=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Mai, A policy server can contain these SLA policies. When a RSVP triggers a COPS REQUEST, from the PEP (router) to the PDP (policy server) the DECISION returned by the PDP reflects whether the resources requested by the RSVP message is within the SLA. http://ietf.org/rfc/rfc2749.txt Another means is that the SLA policy is provisioned into the RSVP router and the policy, if present is used during local RSVP processing. http://ietf.org/internet-drafts/draft-ietf-rap-rsvppcc-pib-01.txt -Diana -----Original Message----- From: Nguyen Thi Mai Trang [mailto:trnguyen@enst.fr] Sent: Monday, April 22, 2002 12:07 PM To: ietf@ietf.org Cc: rap@ops.ietf.org Subject: SLA concept in Intserv/RSVP Hi everybody, I have a question about the notion of SLA (service level agreement) in Intserv/RSVP but I don't know where to post it because the group Intserv is no longer active. It seems that the notion SLA was born in Diffserv architecture. The SLA is necessary because network resources are statically provisioned. It's very clear. In Intserv/RSVP, I don't find the SLA/SLS (service level specification) concept in all concerning draft/RFCs . I wonder if there is no SLA/SLS concept in Intserv/RSVP, how we can make policy decision in Intserv/RSVP. Some clarifications: In Intserv/RSVP, client uses RSVP to request resource in the routers. The routers verify if it has sufficiently resources (Admission control) and the user has the right to request this amount of resource (Policy control) or not. If both are positives, it makes the resource reservation for this flow. My question is that if there is no SLA/SLS, how the network can answer (using COPS-RSVP for example) to the question "Does this client has the right to request such a reservation ?" ? Thank you very much, Mai Trang From owner-rap@ops.ietf.org Tue Apr 23 07:47:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13155 for ; Tue, 23 Apr 2002 07:47:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zyjl-000HFU-00 for rap-data@psg.com; Tue, 23 Apr 2002 04:45:33 -0700 Received: from h-135-207-10-70.research.att.com ([135.207.10.70] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 16zyjl-000HFO-00 for rap@ops.ietf.org; Tue, 23 Apr 2002 04:45:33 -0700 Received: from randy by roam.psg.com with local (Exim 4.00) id 16zyjg-000MBq-00 for rap@ops.ietf.org; Tue, 23 Apr 2002 07:45:28 -0400 Message-ID: <3CC51965.3020600@alcatel.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------090306070207020803070302" Date: Tue, 23 Apr 2002 10:20:53 +0200 From: Yacine El Mghazli To: "rap@ops.ietf.org" Subject: [Fwd: I-D ACTION:draft-yacine-ppvpn-2547bis-pib-00.txt] Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------090306070207020803070302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Please find bellow a new draft describing the BGP/MPLS VPN PIB. thanks, yacine -------- Message d'origine -------- Objet: I-D ACTION:draft-yacine-ppvpn-2547bis-pib-00.txt Date: Fri, 12 Apr 2002 08:02:45 -0400 De: Internet-Drafts@ietf.org Répondre-A: Internet-Drafts@ietf.org A: IETF-Announce: ; CC: ppvpn@ppvpn.francetelecom.com A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP/MPLS VPN Policy Information Base Author(s) : Y. El Mghazli Filename : draft-yacine-ppvpn-2547bis-pib-00.txt Pages : 29 Date : 11-Apr-02 This document describes a Policy Information Base (PIB) for a device implementing the BGP/MPLS VPN [2547bis] Architecture. The Provisioning Classes defined here provide policy control of resources implementing the BGP/MPLS VPN Architecture. These Provisioning Classes can be used with other non BGP/MPLS VPN Provisioning Classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirements to device resource capability and usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-2547bis-pib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yacine-ppvpn-2547bis-pib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yacine-ppvpn-2547bis-pib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090306070207020803070302 Content-Type: text/plain; name="draft-yacine-ppvpn-2547bis-pib-00.txt" Content-Disposition: inline; filename="draft-yacine-ppvpn-2547bis-pib-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020411132913.I-D@ietf.org> --------------090306070207020803070302-- From owner-rap@ops.ietf.org Thu Apr 25 21:25:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10680 for ; Thu, 25 Apr 2002 21:25:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 170uPh-000O2G-00 for rap-data@psg.com; Thu, 25 Apr 2002 18:20:41 -0700 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.36 #1) id 170uPh-000O2A-00 for rap@ops.ietf.org; Thu, 25 Apr 2002 18:20:41 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.41 2002/04/22 23:29:17 root Exp $) with ESMTP id g3Q1JoI20860 for ; Fri, 26 Apr 2002 01:19:50 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3Q1J3b27407 for ; Fri, 26 Apr 2002 01:19:03 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002042518210009960 for ; Thu, 25 Apr 2002 18:21:01 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Apr 2002 18:20:39 -0700 Message-ID: <59885C5E3098D511AD690002A5072D3C053E867E@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org Subject: Test - please ignore Date: Thu, 25 Apr 2002 18:20:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Just checking to see if the list is functioning properly.