From owner-rap@ops.ietf.org Mon Apr 2 05:34:50 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19570 for ; Mon, 2 Apr 2001 05:34:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14k0iI-000NJK-00 for rap-data@psg.com; Mon, 02 Apr 2001 02:33:30 -0700 Received: from femail3.rdc1.on.home.com ([24.2.9.90]) by psg.com with esmtp (Exim 3.16 #1) id 14k0iH-000NJ4-00 for rap@ops.ietf.org; Mon, 02 Apr 2001 02:33:29 -0700 Received: from cr147232b ([24.112.129.233]) by femail3.rdc1.on.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010402093245.OHFH12540.femail3.rdc1.on.home.com@cr147232b> for ; Mon, 2 Apr 2001 02:32:45 -0700 Message-ID: <009501c0bb57$e51d37a0$e9817018@cr147232b> From: "Andreas Polyrakis" To: "IETF RAP WG" Subject: PIB parser Date: Mon, 2 Apr 2001 05:32:54 -0400 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I wonder if there is any PIB syntax parser or any similar tools available. I have seen similar postings in the past in this list, suggesting that the PIB should be transformed into a MIB according to appendix A of SPPI, and then be parsed as a MIB... But I wonder if any tools have appeared since then... If no such tools are available, and since my experience with MIBs is limited, could someone suggest me one such tool? All I want to do is (mainly) check if a PIB that I have defined is syntactically correct... thanks in advance, Andreas From owner-rap@ops.ietf.org Thu Apr 5 05:04:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25406 for ; Thu, 5 Apr 2001 05:03:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14l5eF-000Bk0-00 for rap-data@psg.com; Thu, 05 Apr 2001 02:01:47 -0700 Received: from na5.alcatel.fr ([194.133.58.5] helo=mel.alcatel.fr) by psg.com with esmtp (Exim 3.16 #1) id 14l5eE-000Bjl-00 for rap@ops.ietf.org; Thu, 05 Apr 2001 02:01:46 -0700 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA19086; Thu, 5 Apr 2001 10:51:42 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA01039; Thu, 5 Apr 2001 10:53:43 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id KAA20336; Thu, 5 Apr 2001 10:59:23 +0200 (MET DST) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id KAA26033; Thu, 5 Apr 2001 10:59:29 +0200 (MET DST) Message-ID: <005301c0bdae$6d408d00$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: , "Rawlins, Diana" Cc: "Iliff, Tina" , "Joel M. Halpern" , "Brian E Carpenter" References: <492EB4A3F68CD411ABE800508B69362E3F56B9@RIPEXCH002.wcomnet.com> <3ACB7544.97E1174F@hursley.ibm.com> Subject: Re: [Diffserv] CountActTable Date: Thu, 5 Apr 2001 10:57:21 +0200 Organization: Alcatel R&I 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the framework of COPS-PR configuration, is it important to be able to install/remove/report counters via the DiffServ PIB ? What do think people involved with the accounting PIB ? To my mind I hardly understand why one could not install a counter with COPS-PR in order to monitor it by SNMP, or even to report it via COPS-PR... I'm also interested in the reasons which made DS PIB authors remove the CountActTable from the PIB... I guess they must have good ones ! Thanks Yacine ----- Original Message ----- From: "Brian E Carpenter" To: "Iliff, Tina" Cc: Sent: Wednesday, April 04, 2001 9:25 PM Subject: Re: [Diffserv] CountActTable > I don't see the issue for the MIB: it does have counters and nobody is > proposing to take them away. If you want counters in the PIB, now > is the time to say so since there will be a new version very soon. > The model isn't going to answer that question for you. > > Brian > > > "Iliff, Tina" wrote: > > > > Here are some excerpts from diffserv-model-06: > > > > At the lowest level considered here, are individual functional datapath elements, each with their own configuration parameters > > and management counters and flags. > > > > using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management > > functions such as billing applications. > > > > I find these excerpts unclear as to determining if a PIB or MIB or both should implement a data structure to support the > > definition of a Counter Action. > > > > Tina Iliff > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@longsys.com] > > Sent: Wednesday, April 04, 2001 12:14 PM > > To: diffserv@ietf.org > > Subject: RE: [Diffserv] CountActTable > > > > The Count Action is a diffserv packet handling action. Including it in a > > configuration causes counting to be done. It sure seems that this action > > ought to be configurable with the PIB, just like every other Diffserv > > packet handling action (Meter, Mark, Drop). Otherwise, one would have to > > use SNMP to CONFIGURE this element in order to later use SNMP to retreive > > the counts. > > > > This Action is not itself a counter that would go in an Accounting PIB, or > > only in an SNMP MIB. > > > > Yours, > > Joel M. Halpern > > > > At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > > > >Yacine, > > > > > >Like I said, it is just an assumption or a guess. Someone else will have > > >to answer. The Accounting PIB may be a good place for a > > >counter. However, I have not taken a look at that draft in a while. > > > > > >Tina Iliff > > >-----Original Message----- From: Yacine El Mghazli > > >[mailto:yacine.el_mghazli@ms.alcate > > >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; > > >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > > > > > I am just guessing here but it makes more sense to me to only have a > > > count > action in the MIB and not in the PIB. I do not consider > > > counting of packets > traversing certain datapath functional elements a > > > piece of policy; however, > I do consider it as part of a network nodes > > > management. > > > > > >Do you mean that counting packets is only managed using SNMP ? > > > > > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > > > Mghazli > > > > [mailto:yacine.el_mghazli@alcatel.fr] > > > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > > Tables > > A general extensible framework and examples of > > > > parameterization > > tables for Absolute Drop, Mark and Count > > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > > Action Table in the PIB ? > However there is an CountActTable in the > > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > > ---------------------------------------------------------------------- > > > > Alcatel R&I > Software and Services Strategic Program - > > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > > > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > > ---------------------------------------------------------------------- > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > From owner-rap@ops.ietf.org Thu Apr 5 11:18:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04823 for ; Thu, 5 Apr 2001 11:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lBWL-0003Sk-00 for rap-data@psg.com; Thu, 05 Apr 2001 08:18:01 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.16 #1) id 14lBWJ-0003Rc-00 for rap@ops.ietf.org; Thu, 05 Apr 2001 08:18:00 -0700 Received: from hdcvwall.wipsys.stph.net (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id UAA23749 for ; Thu, 5 Apr 2001 20:49:50 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GBBRWJ00.EAJ for ; Thu, 5 Apr 2001 20:49:31 +0530 Message-ID: <3ACC8B4F.727791BB@wipro.com> Date: Thu, 05 Apr 2001 20:42:15 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF RAP WG Subject: Keep alive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This is a query regarding Keep Alive message time. While generating Keep alive messages, Does the COPS client need to take previous message (from Server/to client) transaction time stamp in deciding the time to send Keep alive message? From sec.3.9, It looks like time stamp of last sent Keep alive message is to be considered. But sec.4.6, mentioned "any other COPS message" in the explanation. Could some one clarify this? ------------------------------------------------------------------- text related to this query from RFC2748 is given below. 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP The keep-alive message MUST be transmitted by the PEP within the period defined by the minimum of all KA Timer values specified in all received CAT messages for the connection. 4.6 Keep-Alive Operations If either side does not receive a Keep-Alive or any ------ other COPS message within the minimum KA Timer interval from the ------------------ other, the connection SHOULD be considered lost. ------------------------------------------------------------------- thanks Krishna -- Krishna Prasad.Akkineni Telecom & Inter-Networking Solutions WIPRO Technologies, ---------------------------------------------------- The opinions expressed here are my personal opinions and not necessarily those of WIPRO Technologies. ---------------------------------------------------- From owner-rap@ops.ietf.org Thu Apr 5 14:13:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10211 for ; Thu, 5 Apr 2001 14:13:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lEGI-000CYS-00 for rap-data@psg.com; Thu, 05 Apr 2001 11:13:38 -0700 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.16 #1) id 14lEGG-000CW8-00 for rap@ops.ietf.org; Thu, 05 Apr 2001 11:13:36 -0700 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id SAA25954; Thu, 5 Apr 2001 18:12:22 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 05 Apr 2001 18:12:21 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2GMQMJ9P>; Thu, 5 Apr 2001 11:12:19 -0700 Message-ID: <10C8636AE359D4119118009027AE998704F39E76@FMSMSX34> From: "Durham, David" To: "'Krishna Prasad Akkineni'" , "'IETF RAP WG'" Subject: RE: Keep alive Date: Thu, 5 Apr 2001 11:12:14 -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 The Keep Alive messages must sent by the PEP within the periods specified by the PDP according to the RFC. However, KAs may be slightly delayed due to the receipt of other large messages (DECs, RPTs, REQs). So, if communication is happening (messages are still being received) the receiver obviously should not close the connection simply because a KA hasn't arrived as yet. -Dave > -----Original Message----- > From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] > Sent: Thursday, April 05, 2001 8:12 AM > To: IETF RAP WG > Subject: Keep alive > > > Hi, > This is a query regarding Keep Alive message time. > While generating Keep alive messages, Does the COPS client > need to take previous message (from Server/to client) transaction > time stamp in deciding the time to send Keep alive message? > From sec.3.9, It looks like time stamp of last sent Keep alive > message is to be considered. > But sec.4.6, mentioned "any other COPS message" in the > explanation. > Could some one clarify this? > ------------------------------------------------------------------- > text related to this query from RFC2748 is given below. > > 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP > The keep-alive message MUST be transmitted by the PEP within the > period defined by the minimum of all KA Timer values > specified in all > received CAT messages for the connection. > > 4.6 Keep-Alive Operations > > If either side does not receive a Keep-Alive or any > ------ > other COPS message within the minimum KA Timer interval from the > ------------------ > other, the connection SHOULD be considered lost. > ------------------------------------------------------------------- > > thanks > Krishna > > -- > Krishna Prasad.Akkineni > Telecom & Inter-Networking Solutions > WIPRO Technologies, > ---------------------------------------------------- > The opinions expressed here are my personal opinions > and not necessarily those of WIPRO Technologies. > ---------------------------------------------------- > > From owner-rap@ops.ietf.org Thu Apr 5 14:27:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10672 for ; Thu, 5 Apr 2001 14:27:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lETK-000DDS-00 for rap-data@psg.com; Thu, 05 Apr 2001 11:27:06 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14lETJ-000DBq-00 for rap@ops.ietf.org; Thu, 05 Apr 2001 11:27:05 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GBC0091A0IP96@firewall.mcit.com> for rap@ops.ietf.org; Thu, 5 Apr 2001 18:25:37 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBC00D010IJGA@dgismtp02.wcomnet.com>; Thu, 05 Apr 2001 18:25:36 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBC00C940IAE9@dgismtp02.wcomnet.com>; Thu, 05 Apr 2001 18:25:22 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 05 Apr 2001 18:25:21 +0000 Content-return: allowed Date: Thu, 05 Apr 2001 18:25:18 +0000 From: "Iliff, Tina" Subject: RE: Keep alive To: "'Durham, David'" , "'Krishna Prasad Akkineni'" , "'IETF RAP WG'" Cc: "Sunlin, Richard (c)" Message-id: <492EB4A3F68CD411ABE800508B69362E3F56D3@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_HBpObQ8Va05ES4INeZZsSw)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_HBpObQ8Va05ES4INeZZsSw) Content-type: text/plain; charset=ISO-8859-1 I have the same opinion. Why close the connection if the primary messages of the protocol are still being received and the purpose of the protocol is being achieved? Closing the connection prematurely will add overhead and extraneous traffic on the network. Tina Iliff -----Original Message----- From: Durham, David [mailto:david.durham@intel.com] Sent: Thursday, April 05, 2001 1:12 PM To: 'Krishna Prasad Akkineni'; 'IETF RAP WG' Subject: RE: Keep alive The Keep Alive messages must sent by the PEP within the periods specified by the PDP according to the RFC. However, KAs may be slightly delayed due to the receipt of other large messages (DECs, RPTs, REQs). So, if communication is happening (messages are still being received) the receiver obviously should not close the connection simply because a KA hasn't arrived as yet. -Dave > -----Original Message----- > From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] > Sent: Thursday, April 05, 2001 8:12 AM > To: IETF RAP WG > Subject: Keep alive > > > Hi, > This is a query regarding Keep Alive message time. > While generating Keep alive messages, Does the COPS client > need to take previous message (from Server/to client) transaction > time stamp in deciding the time to send Keep alive message? > From sec.3.9, It looks like time stamp of last sent Keep alive > message is to be considered. > But sec.4.6, mentioned "any other COPS message" in the > explanation. > Could some one clarify this? > ------------------------------------------------------------------- > text related to this query from RFC2748 is given below. > > 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP > The keep-alive message MUST be transmitted by the PEP within the > period defined by the minimum of all KA Timer values > specified in all > received CAT messages for the connection. > > 4.6 Keep-Alive Operations > > If either side does not receive a Keep-Alive or any > ------ > other COPS message within the minimum KA Timer interval from the > ------------------ > other, the connection SHOULD be considered lost. > ------------------------------------------------------------------- > > thanks > Krishna > > -- > Krishna Prasad.Akkineni > Telecom & Inter-Networking Solutions > WIPRO Technologies, > ---------------------------------------------------- > The opinions expressed here are my personal opinions > and not necessarily those of WIPRO Technologies. > ---------------------------------------------------- > > --Boundary_(ID_HBpObQ8Va05ES4INeZZsSw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: Keep alive

I have the same opinion.  Why = close the connection if the primary messages of the protocol are still = being received and the purpose of the protocol is being achieved?  = Closing the connection prematurely will add overhead and extraneous = traffic on the network.

Tina Iliff


      -----Original = Message-----
      From:   Durham, David = [mailto:david.durham@intel.com= ]
      Sent:   Thursday, April 05, 2001 1:12 PM
      To:     'Krishna Prasad Akkineni'; 'IETF RAP WG'
      Subject:       = RE: Keep alive

      The Keep Alive messages must sent by = the PEP within the periods specified by
      the PDP according to the RFC. = However, KAs may be slightly delayed due to
      the receipt of other large messages = (DECs, RPTs, REQs). So, if communication
      is happening (messages are still = being received) the receiver obviously
      should not close the connection = simply because a KA hasn't arrived as yet.
      -Dave 

      > -----Original Message-----
      > From: Krishna Prasad Akkineni = [mailto:krishna.akkineni@wipro= .com]
      > Sent: Thursday, April 05, 2001 = 8:12 AM
      > To: IETF RAP WG
      > Subject: Keep alive
      >
      >
      > Hi,
      >      = This is a query regarding Keep Alive message time.
      >    While = generating Keep alive messages, Does the COPS client
      >    need to take = previous message (from Server/to client) transaction
      >    time stamp in = deciding the time to send Keep alive message?
      >    From sec.3.9, = It looks like time stamp of last sent Keep alive
      >    message is to = be considered.
      >    But sec.4.6, = mentioned  "any other COPS message" in the
      > explanation.
      >    Could some one = clarify this?
      >    = -------------------------------------------------------------------
      >    text related = to this query from RFC2748 is given below.
      >   
      >    3.9 Keep-Alive = (KA)  PEP -> PDP, PDP -> PEP
      >    The keep-alive = message MUST be transmitted by the PEP within the
      >    period defined = by the minimum of all KA Timer values
      > specified in all
      >    received CAT = messages for the connection. 
      >
      >    4.6 Keep-Alive = Operations
      >
      >    If either side = does not receive a Keep-Alive or any
      >         = ;            = ;            = ;            = ;    ------
      >    other COPS = message within the minimum KA Timer interval from the
      >    = ------------------
      >    other, the = connection SHOULD be considered lost.
      >    = -------------------------------------------------------------------
      >
      > thanks
      > Krishna
      >
      > --
      > Krishna Prasad.Akkineni
      > Telecom & Inter-Networking = Solutions
      > WIPRO Technologies,
      > = ----------------------------------------------------
      > The opinions expressed here are = my personal opinions
      > and not necessarily those of = WIPRO Technologies.
      > = ----------------------------------------------------
      >
      >

--Boundary_(ID_HBpObQ8Va05ES4INeZZsSw)-- From owner-rap@ops.ietf.org Thu Apr 5 16:24:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13710 for ; Thu, 5 Apr 2001 16:24:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lGIw-000ORk-00 for rap-data@psg.com; Thu, 05 Apr 2001 13:24:30 -0700 Received: from mailhost2.castlenetworks.com ([63.93.189.52] helo=email2.chelmsford.castlenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 14lGIu-000OOU-00 for rap@ops.ietf.org; Thu, 05 Apr 2001 13:24:28 -0700 Received: by email2.chelmsford.castlenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Apr 2001 16:23:57 -0400 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F01CD526F@email2.chelmsford.castlenetworks.com> From: "Moisand, Jerome" To: "'Yacine El Mghazli'" , rap@ops.ietf.org, "Rawlins, Diana" Cc: "Iliff, Tina" , "Joel M. Halpern" , Brian E Carpenter Subject: RE: [Diffserv] CountActTable Date: Thu, 5 Apr 2001 16:22:36 -0400 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 Speaking for my company, yes we feel it is very important to have such counters via COPS reports. Because SNMP is not a very scalable way to get counters on a large number of objects (e.g. IP interfaces which may be as numerous as tens of thousands or more on a given box) in a reliable way. I hope I will not get flamed for this statement! ;-) Plus differentiated services typically come with differentiated charging models (and some of these billing models might be based on volume). So it is key to get service usage (aka accounting) data in association with Diffserv policies. And in a reliable/scalable way. This being said, based on the accounting framework currently defined in the "rap" group, accounting PIBs are clearly separate from the related "provisioning" PIB. And related objects (e.g. classifiers & meters) are referenced via pointers. So it makes sense to not have counters in the Diffserv PIB. As long as there is a "Diffserv accounting PIB" in the works (or the general one described in the accounting framework is applicable). Jerome =========================================== Jerome P. Moisand Senior Product Manager Unisphere Networks One Executive Drive Chelmsford, MA 01824 Tel: 978-848-0648 Fax: 978-848-0399 mailto:jmoisand@UnisphereNetworks.com -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr] Sent: Thursday, April 05, 2001 4:57 AM To: rap@ops.ietf.org; Rawlins, Diana Cc: Iliff, Tina; Joel M. Halpern; Brian E Carpenter Subject: Re: [Diffserv] CountActTable In the framework of COPS-PR configuration, is it important to be able to install/remove/report counters via the DiffServ PIB ? What do think people involved with the accounting PIB ? To my mind I hardly understand why one could not install a counter with COPS-PR in order to monitor it by SNMP, or even to report it via COPS-PR... I'm also interested in the reasons which made DS PIB authors remove the CountActTable from the PIB... I guess they must have good ones ! Thanks Yacine ----- Original Message ----- From: "Brian E Carpenter" To: "Iliff, Tina" Cc: Sent: Wednesday, April 04, 2001 9:25 PM Subject: Re: [Diffserv] CountActTable > I don't see the issue for the MIB: it does have counters and nobody is > proposing to take them away. If you want counters in the PIB, now > is the time to say so since there will be a new version very soon. > The model isn't going to answer that question for you. > > Brian > > > "Iliff, Tina" wrote: > > > > Here are some excerpts from diffserv-model-06: > > > > At the lowest level considered here, are individual functional datapath elements, each with their own configuration parameters > > and management counters and flags. > > > > using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management > > functions such as billing applications. > > > > I find these excerpts unclear as to determining if a PIB or MIB or both should implement a data structure to support the > > definition of a Counter Action. > > > > Tina Iliff > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@longsys.com] > > Sent: Wednesday, April 04, 2001 12:14 PM > > To: diffserv@ietf.org > > Subject: RE: [Diffserv] CountActTable > > > > The Count Action is a diffserv packet handling action. Including it in a > > configuration causes counting to be done. It sure seems that this action > > ought to be configurable with the PIB, just like every other Diffserv > > packet handling action (Meter, Mark, Drop). Otherwise, one would have to > > use SNMP to CONFIGURE this element in order to later use SNMP to retreive > > the counts. > > > > This Action is not itself a counter that would go in an Accounting PIB, or > > only in an SNMP MIB. > > > > Yours, > > Joel M. Halpern > > > > At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > > > >Yacine, > > > > > >Like I said, it is just an assumption or a guess. Someone else will have > > >to answer. The Accounting PIB may be a good place for a > > >counter. However, I have not taken a look at that draft in a while. > > > > > >Tina Iliff > > >-----Original Message----- From: Yacine El Mghazli > > >[mailto:yacine.el_mghazli@ms.alcate > > >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; > > >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > > > > > I am just guessing here but it makes more sense to me to only have a > > > count > action in the MIB and not in the PIB. I do not consider > > > counting of packets > traversing certain datapath functional elements a > > > piece of policy; however, > I do consider it as part of a network nodes > > > management. > > > > > >Do you mean that counting packets is only managed using SNMP ? > > > > > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > > > Mghazli > > > > [mailto:yacine.el_mghazli@alcatel.fr] > > > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > > Tables > > A general extensible framework and examples of > > > > parameterization > > tables for Absolute Drop, Mark and Count > > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > > Action Table in the PIB ? > However there is an CountActTable in the > > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > > ---------------------------------------------------------------------- > > > > Alcatel R&I > Software and Services Strategic Program - > > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > > > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > > ---------------------------------------------------------------------- > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > From owner-rap@ops.ietf.org Thu Apr 5 16:38:01 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13929 for ; Thu, 5 Apr 2001 16:37:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lGVp-0000Cu-00 for rap-data@psg.com; Thu, 05 Apr 2001 13:37:49 -0700 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14lGVm-0000AC-00 for rap@ops.ietf.org; Thu, 05 Apr 2001 13:37:46 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GBC0023W6J372@firewall.mcit.com> for rap@ops.ietf.org; Thu, 5 Apr 2001 20:35:28 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBC00J016J3P5@dgismtp02.wcomnet.com>; Thu, 05 Apr 2001 20:35:27 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBC00I7B6IO8Q@dgismtp02.wcomnet.com>; Thu, 05 Apr 2001 20:35:12 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 05 Apr 2001 20:35:12 +0000 Content-return: allowed Date: Thu, 05 Apr 2001 20:35:10 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Moisand, Jerome'" , "'Yacine El Mghazli'" , rap@ops.ietf.org, "Rawlins, Diana" Cc: "Joel M. Halpern" , Brian E Carpenter Message-id: <492EB4A3F68CD411ABE800508B69362E3F56DA@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_pfyGo8XIGzL3bfKTAiftkQ)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_pfyGo8XIGzL3bfKTAiftkQ) Content-type: text/plain; charset=ISO-8859-1 Agree. Tina Iliff -----Original Message----- From: Moisand, Jerome [mailto:jmoisand@unispherenetworks.com] Sent: Thursday, April 05, 2001 3:23 PM To: 'Yacine El Mghazli'; rap@ops.ietf.org; Rawlins, Diana Cc: Iliff, Tina; Joel M. Halpern; Brian E Carpenter Subject: RE: [Diffserv] CountActTable Speaking for my company, yes we feel it is very important to have such counters via COPS reports. Because SNMP is not a very scalable way to get counters on a large number of objects (e.g. IP interfaces which may be as numerous as tens of thousands or more on a given box) in a reliable way. I hope I will not get flamed for this statement! ;-) Plus differentiated services typically come with differentiated charging models (and some of these billing models might be based on volume). So it is key to get service usage (aka accounting) data in association with Diffserv policies. And in a reliable/scalable way. This being said, based on the accounting framework currently defined in the "rap" group, accounting PIBs are clearly separate from the related "provisioning" PIB. And related objects (e.g. classifiers & meters) are referenced via pointers. So it makes sense to not have counters in the Diffserv PIB. As long as there is a "Diffserv accounting PIB" in the works (or the general one described in the accounting framework is applicable). Jerome =========================================== Jerome P. Moisand Senior Product Manager Unisphere Networks One Executive Drive Chelmsford, MA 01824 Tel: 978-848-0648 Fax: 978-848-0399 mailto:jmoisand@UnisphereNetworks.com -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr] Sent: Thursday, April 05, 2001 4:57 AM To: rap@ops.ietf.org; Rawlins, Diana Cc: Iliff, Tina; Joel M. Halpern; Brian E Carpenter Subject: Re: [Diffserv] CountActTable In the framework of COPS-PR configuration, is it important to be able to install/remove/report counters via the DiffServ PIB ? What do think people involved with the accounting PIB ? To my mind I hardly understand why one could not install a counter with COPS-PR in order to monitor it by SNMP, or even to report it via COPS-PR... I'm also interested in the reasons which made DS PIB authors remove the CountActTable from the PIB... I guess they must have good ones ! Thanks Yacine ----- Original Message ----- From: "Brian E Carpenter" To: "Iliff, Tina" Cc: Sent: Wednesday, April 04, 2001 9:25 PM Subject: Re: [Diffserv] CountActTable > I don't see the issue for the MIB: it does have counters and nobody is > proposing to take them away. If you want counters in the PIB, now > is the time to say so since there will be a new version very soon. > The model isn't going to answer that question for you. > > Brian > > > "Iliff, Tina" wrote: > > > > Here are some excerpts from diffserv-model-06: > > > > At the lowest level considered here, are individual functional datapath elements, each with their own configuration parameters > > and management counters and flags. > > > > using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management > > functions such as billing applications. > > > > I find these excerpts unclear as to determining if a PIB or MIB or both should implement a data structure to support the > > definition of a Counter Action. > > > > Tina Iliff > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@longsys.com] > > Sent: Wednesday, April 04, 2001 12:14 PM > > To: diffserv@ietf.org > > Subject: RE: [Diffserv] CountActTable > > > > The Count Action is a diffserv packet handling action. Including it in a > > configuration causes counting to be done. It sure seems that this action > > ought to be configurable with the PIB, just like every other Diffserv > > packet handling action (Meter, Mark, Drop). Otherwise, one would have to > > use SNMP to CONFIGURE this element in order to later use SNMP to retreive > > the counts. > > > > This Action is not itself a counter that would go in an Accounting PIB, or > > only in an SNMP MIB. > > > > Yours, > > Joel M. Halpern > > > > At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > > > >Yacine, > > > > > >Like I said, it is just an assumption or a guess. Someone else will have > > >to answer. The Accounting PIB may be a good place for a > > >counter. However, I have not taken a look at that draft in a while. > > > > > >Tina Iliff > > >-----Original Message----- From: Yacine El Mghazli > > >[mailto:yacine.el_mghazli@ms.alcate > > >l.fr] Sent: Wednesday, April 04, 2001 10:07 AM To: Iliff, Tina; > > >diffserv@ietf.org Subject: Re: [Diffserv] CountActTable > > > > > > > I am just guessing here but it makes more sense to me to only have a > > > count > action in the MIB and not in the PIB. I do not consider > > > counting of packets > traversing certain datapath functional elements a > > > piece of policy; however, > I do consider it as part of a network nodes > > > management. > > > > > >Do you mean that counting packets is only managed using SNMP ? > > > > > > > Tina Iliff > > > -----Original Message----- > From: Yacine El > > > Mghazli > > > > [mailto:yacine.el_mghazli@alcatel.fr] > > > > Sent: Wednesday, April 04, 2001 7:39 AM > To: diffserv@ietf.org > > > > Subject: [Diffserv] CountActTable > > In the lattest DS PIB : > > > > > Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > > Tables > > A general extensible framework and examples of > > > > parameterization > > tables for Absolute Drop, Mark and Count > > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > > Action Table in the PIB ? > However there is an CountActTable in the > > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > > ---------------------------------------------------------------------- > > > > Alcatel R&I > Software and Services Strategic Program - > > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 1 > > > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > > ---------------------------------------------------------------------- > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > --Boundary_(ID_pfyGo8XIGzL3bfKTAiftkQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

Agree.
Tina Iliff


      -----Original = Message-----
      From:   Moisand, Jerome = [mailto:jmoisand@unisphere= networks.com]
      Sent:   Thursday, April 05, 2001 3:23 PM
      To:     'Yacine El Mghazli'; rap@ops.ietf.org; Rawlins, = Diana
      Cc:     Iliff, Tina; Joel M. Halpern; Brian E Carpenter
      Subject:       = RE: [Diffserv] CountActTable


      Speaking for my company, yes we feel = it is very important to have such
      counters via COPS reports.

      Because SNMP is not a very scalable = way to get counters on a large number of
      objects (e.g. IP interfaces which may = be as numerous as tens of thousands or
      more on a given box) in a reliable = way. I hope I will not get flamed for
      this statement!  ;-)

      Plus differentiated services typically = come with differentiated charging
      models (and some of these billing = models might be based on volume). So it is
      key to get service usage (aka = accounting) data in association with Diffserv
      policies. And in a reliable/scalable = way.

      This being said, based on the = accounting framework currently defined in the
      "rap" group, accounting = PIBs are clearly separate from the related
      "provisioning" PIB. And = related objects (e.g. classifiers & meters) are
      referenced via pointers.

      So it makes sense to not have counters = in the Diffserv PIB. As long as there
      is a "Diffserv accounting = PIB" in the works (or the general one described in
      the accounting framework is = applicable).

      Jerome

      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
      Jerome P. Moisand
      Senior Product Manager
      Unisphere Networks
      One Executive Drive  Chelmsford, = MA 01824
      Tel: 978-848-0648  Fax: = 978-848-0399
      mailto:jmoisand@Unisphere= Networks.com



      -----Original Message-----
      From: Yacine El Mghazli [mailto:yacine.el_mghazli= @ms.alcatel.fr]
      Sent: Thursday, April 05, 2001 4:57 = AM
      To: rap@ops.ietf.org; Rawlins, = Diana
      Cc: Iliff, Tina; Joel M. Halpern; = Brian E Carpenter
      Subject: Re: [Diffserv] = CountActTable


      In the framework of COPS-PR = configuration, is it important to be able to
      install/remove/report counters via = the DiffServ PIB ? What do think people
      involved with the accounting PIB = ?
      To my mind I hardly understand why = one could not install a counter with
      COPS-PR in order to monitor it by = SNMP, or even to report it via COPS-PR...
      I'm also interested in the reasons = which made DS PIB authors remove the
      CountActTable from the PIB... I guess = they must have good ones !

      Thanks
      Yacine

      ----- Original Message -----
      From: "Brian E Carpenter" = <brian@hursley.ibm.com>
      To: "Iliff, Tina" = <Tina.Iliff@WCOM.Com>
      Cc: <diffserv@ietf.org>
      Sent: Wednesday, April 04, 2001 9:25 = PM
      Subject: Re: [Diffserv] = CountActTable


      > I don't see the issue for the = MIB: it does have counters and nobody is
      > proposing to take them away. If = you want counters in the PIB, now
      > is the time to say so since = there will be a new version very soon.
      > The model isn't going to answer = that question for you.
      >
      >    Brian
      >
      > > "Iliff, Tina" = wrote:
      > >
      > > Here are some excerpts from = diffserv-model-06:
      > >
      > > At the lowest level = considered here, are individual functional datapath
      elements, each with their own = configuration parameters
      > > and management counters and = flags.
      > >
      > > using a Counter element = downstream of the Meter, it might also be used
      to help in collecting data for = out-of-band management
      > > functions such as billing = applications.
      > >
      > > I find these excerpts = unclear as to determining if a PIB or MIB or both
      should implement a data structure to = support the
      > > definition of a Counter = Action.
      > >
      > > Tina Iliff
      > >
      > = >           = -----Original Message-----
      > = >           = From:   Joel M. Halpern [mailto:joel@longsys.com]
      > >     = ;      Sent:   Wednesday, April 04, = 2001 12:14 PM
      > = >           = To:     diffserv@ietf.org
      > = >           = Subject:        RE: [Diffserv] = CountActTable
      > >
      > = >           The = Count Action is a diffserv packet handling action.
      Including it in a
      > = >           = configuration causes counting to be done.  It sure seems = that
      this action
      > = >           ought = to be configurable with the PIB, just like every other
      Diffserv
      > = >           packet = handling action (Meter, Mark, Drop).  Otherwise, one
      would have to
      > = >           use = SNMP to CONFIGURE this element in order to later use SNMP
      to retreive
      > = >           the = counts.
      > >
      > = >           This = Action is not itself a counter that would go in an
      Accounting PIB, or
      > = >           only = in an SNMP MIB.
      > >
      > = >           = Yours,
      > = >           Joel = M. Halpern
      > >
      > = >           At = 03:13 PM 4/4/01 +0000, Iliff, Tina wrote:
      > >
      > = >           = >Yacine,
      > = >           = >
      > = >           = >Like I said, it is just an assumption or a guess.  = Someone
      else will have
      > = >           >to = answer.  The Accounting PIB may be a good place for a
      > = >           = >counter.  However, I have not taken a look at that draft in = a
      while.
      > = >           = >
      > = >           = >Tina Iliff
      > = >           = >-----Original Message-----  From:   Yacine El = Mghazli
      > >
      >[<mailto:yacine.el_mghazli@ms.alcatel.fr>mailto:yacine.el_mghazli@ms.= alcate
      > = >           = >l.fr]  Sent:   Wednesday, April 04, 2001 10:07 = AM  To:
      Iliff, Tina;
      > = >           = >diffserv@ietf.org  = Subject:        Re: = [Diffserv]
      CountActTable
      > = >           = >
      > = >           > = > I am just guessing here but it makes more sense to me to
      only have a
      > = >           > = count  > action in the MIB and not in the PIB.  I do = not
      consider
      > = >           > = counting of  packets  > traversing certain datapath
      functional elements a
      > = >           > = piece of policy;  however,  > I do consider it as part of = a
      network nodes
      > = >           > = management.
      > = >           = >
      > = >           >Do = you mean that counting packets is only managed using SNMP
      ?
      > = >           = >
      > = >           > = > Tina Iliff  >  >  > -----Original = Message-----  > From:
      Yacine El
      > = >           > = Mghazli  >
      > = >           = >
      [<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr]
      > = >            = >   > Sent: Wednesday, April 04, 2001 7:39 AM  = > To:
      diffserv@ietf.org  >
      > = >           > = Subject: [Diffserv] CountActTable  >  > In the lattest = DS
      PIB :  >  >
      > = >           > = Quoted from the draft-ietf-diffserv-pib-03.txt (page 5) :  = >
      > Action
      > = >           > = Tables  > >      A general = extensible framework and examples
      of  >
      > >     = ;      > parameterization  > = >      tables for Absolute Drop, = Mark
      and Count
      > = >           > = actions.  >  > and page 11 :  > > = 4.5.1.  DSCP Mark Action
      PRC  > >
      > = >           > = (...)  > > 4.5.2.  Absolute Drop Action  = >  > So why is
      there no Count
      > = >           > = Action Table in the PIB ?  > However there is an
      CountActTable in the
      > = >           > = MIB...I feel  > confused.  >  > Thanx  = >  > -- Yacine El
      Mghazli  >  >
      > >






          > = ----------------------------------------------------------------------
      >
      > = >            = >   Alcatel R&I  >   Software and = Services Strategic
      Program -
      > = >           > = VIPeR  >   Marcoussis, France  >   = Tel  +33 1 69 63 41 87  >
      Fax  +33 1
      > = >           > = 69 63 11 69  >   = yacine.el_mghazli@ms.alcatel.fr  >  >
      > >






          > = ----------------------------------------------------------------------
      >
      >
      > = _______________________________________________
      > diffserv mailing list
      > diffserv@ietf.org
      > http://www1.ietf.org/mailman/listinfo/diffserv
      > Archive:
      http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.h
      tml
      >

--Boundary_(ID_pfyGo8XIGzL3bfKTAiftkQ)-- From owner-rap@ops.ietf.org Fri Apr 6 01:59:04 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27699 for ; Fri, 6 Apr 2001 01:59:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lPEa-00079c-00 for rap-data@psg.com; Thu, 05 Apr 2001 22:56:36 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.16 #1) id 14lPEW-00077C-00 for rap@ops.ietf.org; Thu, 05 Apr 2001 22:56:33 -0700 Received: from hdcvwall.wipsys.stph.net (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id LAA10025 for ; Fri, 6 Apr 2001 11:28:15 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GBCWKH00.D8D; Fri, 6 Apr 2001 11:27:53 +0530 Message-ID: <3ACD592F.DA5F5A2A@wipro.com> Date: Fri, 06 Apr 2001 11:20:39 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Durham David" CC: "'IETF RAP WG'" Subject: Re: Keep alive References: <10C8636AE359D4119118009027AE998704F39E76@FMSMSX34> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Thanks for the explanation. I understand that Server must consider last received message(KA/any other) timestamp in to consideration before closing the connection. Actually, my query is related to client side. Whether COPS client also should behave in the same way as that of server? or Should Client need to send KA exactly between 1/4th and 3/4th time of KA minimum timer provided by server? i.e., Is KA message needs to be triggered independent of any message other than previous KA message time stamp? Thanks again. Krishna "Durham, David" wrote: > > The Keep Alive messages must sent by the PEP within the periods specified by > the PDP according to the RFC. However, KAs may be slightly delayed due to > the receipt of other large messages (DECs, RPTs, REQs). So, if communication > is happening (messages are still being received) the receiver obviously > should not close the connection simply because a KA hasn't arrived as yet. > -Dave > > > -----Original Message----- > > From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] > > Sent: Thursday, April 05, 2001 8:12 AM > > To: IETF RAP WG > > Subject: Keep alive > > > > > > Hi, > > This is a query regarding Keep Alive message time. > > While generating Keep alive messages, Does the COPS client > > need to take previous message (from Server/to client) transaction > > time stamp in deciding the time to send Keep alive message? > > From sec.3.9, It looks like time stamp of last sent Keep alive > > message is to be considered. > > But sec.4.6, mentioned "any other COPS message" in the > > explanation. > > Could some one clarify this? > > ------------------------------------------------------------------- > > text related to this query from RFC2748 is given below. > > > > 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP > > The keep-alive message MUST be transmitted by the PEP within the > > period defined by the minimum of all KA Timer values > > specified in all > > received CAT messages for the connection. > > > > 4.6 Keep-Alive Operations > > > > If either side does not receive a Keep-Alive or any > > ------ > > other COPS message within the minimum KA Timer interval from the > > ------------------ > > other, the connection SHOULD be considered lost. > > ------------------------------------------------------------------- > > > > thanks > > Krishna -- Krishna Prasad.Akkineni Telecom & Inter-Networking Solutions WIPRO Technologies, ---------------------------------------------------- The opinions expressed here are my personal opinions and not necessarily those of WIPRO Technologies. ---------------------------------------------------- From owner-rap@ops.ietf.org Fri Apr 6 13:05:30 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14565 for ; Fri, 6 Apr 2001 13:05:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lZe3-0007XV-00 for rap-data@psg.com; Fri, 06 Apr 2001 10:03:35 -0700 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by psg.com with esmtp (Exim 3.16 #1) id 14lZe2-0007UT-00 for rap@ops.ietf.org; Fri, 06 Apr 2001 10:03:34 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GBD0016YRCTJR@firewall.mcit.com> for rap@ops.ietf.org; Fri, 6 Apr 2001 17:02:53 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBD00F01RCK3H@dgismtp02.wcomnet.com>; Fri, 06 Apr 2001 17:02:52 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBD00AOPRCF2Y@dgismtp02.wcomnet.com>; Fri, 06 Apr 2001 17:02:39 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 06 Apr 2001 17:02:39 +0000 Content-return: allowed Date: Fri, 06 Apr 2001 17:02:36 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] CountActTable To: "'Joel M. Halpern'" , diffserv@ietf.org, "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F56E5@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g) Content-type: text/plain; charset=ISO-8859-1 So, in other words, you are implying that a boolean value should be added to each PIB PRC to specify whether or not to count? I see the use; however, I do not think it is applicable to the Diffserv PIB since a counter is not a specific piece of QoS information. I would recommend adding it to the Framework PIB (for example, add a boolean value to the frwkPrcSupport PRC) if it is added to a PIB at all. Tina Iliff -----Original Message----- From: Joel M. Halpern [mailto:joel@longsys.com] Sent: Friday, April 06, 2001 10:00 AM To: diffserv@ietf.org Subject: RE: [Diffserv] CountActTable There are no defined implicit count actions. The point of including the actions explicitily in the MIB / Model (and presumably PIB) is that depending upon the particular usage intended by the administrator, one may want to count at different points. The Count Actions define where counting is done. Yours, Joel M. Halpern At 01:45 PM 4/6/01 +0000, Iliff, Tina wrote: >However, it seems logical that the count action would be implicit and >therefore, does not need configuration parameters within a policy >set. For example, if the Accounting Timer is set, then the PEP should >"turn on" its counters; otherwise, the counters are "disabled". > >Tina Iliff >-----Original Message----- From: Joel M. Halpern >[mailto:joel@longsys.com] Sent: Wednesday, >April 04, 2001 12:14 PM To: diffserv@ietf.org Subject: RE: >[Diffserv] CountActTable > >The Count Action is a diffserv packet handling action. Including it in >a configuration causes counting to be done. It sure seems that this >action ought to be configurable with the PIB, just like every other >Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would >have to use SNMP to CONFIGURE this element in order to later use SNMP to >retreive the counts. > >This Action is not itself a counter that would go in an Accounting PIB, >or only in an SNMP MIB. > >Yours, Joel M. Halpern > >At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > >Yacine, > >Like I said, it is just an assumption or a guess. Someone > else will have >to answer. The Accounting PIB may be a good place for > a >counter. However, I have not taken a look at that draft in a > while. > >Tina Iliff >-----Original Message----- From: Yacine El > Mghazli > >[<mailto:yacine.el_mghazli@ms.a > lcatel.fr>mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, > April 04, 2001 10:07 AM To: Iliff, > Tina; >diffserv@ietf.org Subject: Re: [Diffserv] > CountActTable > > > I am just guessing here but it makes more sense to > me to only have a > count > action in the MIB and not in the PIB. I do > not consider > counting of packets > traversing certain datapath > functional elements a > piece of policy; however, > I do consider it as > part of a network nodes > management. > >Do you mean that counting > packets is only managed using SNMP ? > > > Tina Iliff > > > > -----Original Message----- > From: Yacine El > Mghazli > > > [<mailto:yacine.el_mghazli@alcatel.fr > >mailto:yacine.el_mghazli@alcatel.fr] > > Sent: Wednesday, April 04, > 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] > CountActTable > > In the lattest DS PIB : > > > Quoted from the > draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > Tables > > A general extensible framework and examples of > > > parameterization > > tables for Absolute Drop, Mark and Count > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > Action Table in the PIB ? > However there is an CountActTable in the > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > > Alcatel R&I > Software and Services Strategic Program - > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 > 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > ---------------------------------------------------------------------- > > > > > _______________________________________________ > diffserv > > mailing list > diffserv@ietf.org > > > <http://www1.ietf.org/mail > man/listinfo/diffserv>http://www1.ietf.org/mailm > > an/listinfo/diffserv > > Archive: > > > < s>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > s > > t.h> l>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > > list.h > tml > > >_______________________________________________ diffserv mailing >list diffserv@ietf.org >http://www1.ietf.org/mailma >n/listinfo/diffserv Archive: >.html>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai >llist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable

So, in other words, you are implying = that a boolean value should be added to each PIB PRC to specify whether = or not to count?  I see the use; however, I do not think it is = applicable to the Diffserv PIB since a counter is not a specific piece = of QoS information.  I would recommend adding it to the Framework = PIB (for example, add a boolean value to the frwkPrcSupport PRC) if it = is added to a PIB at all.

Tina Iliff


      -----Original = Message-----
      From:   Joel M. Halpern = [mailto:joel@longsys.com]=
      Sent:   Friday, April 06, 2001 10:00 AM
      To:     diffserv@ietf.org
      Subject:       = RE: [Diffserv] CountActTable

      There are no defined implicit count = actions.  The point of including the
      actions explicitily in the MIB / = Model (and presumably PIB) is that
      depending upon the particular usage = intended by the administrator, one may
      want to count at different = points.  The Count Actions define where counting
      is done.

      Yours,
      Joel M. Halpern

      At 01:45 PM 4/6/01 +0000, Iliff, Tina = wrote:

      >However, it seems logical that the = count action would be implicit and
      >therefore, does not need = configuration parameters within a policy
      >set.  For example, if the = Accounting Timer is set, then the PEP should
      >"turn on" its counters; = otherwise, the counters are "disabled".
      >
      >Tina Iliff
      >-----Original Message-----  = From:   Joel M. Halpern
      >[<mailto:joel@longsys.com>mailto:joel@longsys.com]  = Sent:   Wednesday,
      >April 04, 2001 12:14 PM  = To:     diffserv@ietf.org  = Subject:        RE:
      >[Diffserv] CountActTable
      >
      >The Count Action is a diffserv = packet handling action.  Including it in
      >a  configuration causes = counting to be done.  It sure seems that this
      >action ought to be configurable = with the PIB, just like every other
      >Diffserv packet handling action = (Meter, Mark, Drop).  Otherwise, one would
      >have to use SNMP to CONFIGURE = this element in order to later use SNMP to
      >retreive the counts.
      >
      >This Action is not itself a = counter that would go in an Accounting PIB,
      >or  only in an SNMP = MIB.
      >
      >Yours,  Joel M. = Halpern
      >
      >At 03:13 PM 4/4/01 +0000, Iliff, = Tina wrote:
      >
      > >Yacine,  >  = >Like I said, it is just an assumption or a guess.  Someone =
      > else will have  >to = answer.  The Accounting PIB may be a good place for
      > a >counter.  However, I = have not taken a look at that draft in a
      > while.  >  >Tina = Iliff  >-----Original Message-----  From:   = Yacine El
      > Mghazli
       >  >[<<mailto:yacine.el_mghazli= @ms.alcatel.fr>mailto:yacine.el_mghazli@ms.a=
      > lcatel.fr>mailto:yacine.el_mghazli@ms.= alcate >l.fr]  Sent:   Wednesday,
      > April 04, 2001 10:07 AM  = To:     Iliff,
      > Tina; = >diffserv@ietf.org  = Subject:        Re: [Diffserv] =
      > CountActTable  >  = > > I am just guessing here but it makes more sense to
      > me to only have a  > = count  > action in the MIB and not in the PIB.  I do =
      > not consider > counting = of  packets  > traversing certain datapath
      > functional elements a > piece = of policy;  however,  > I do consider it as
      > part of a network nodes > = management.  >  >Do you mean that counting
      > packets is only managed using = SNMP ?  >  > > Tina Iliff  >  = >  >
      > -----Original Message-----  = > From: Yacine El  > Mghazli  > >
      > [<<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr
       > >mailto:yacine.el_mghazli@al= catel.fr]  >   > Sent: Wednesday, April 04, =
      > 2001 7:39 AM  > To: = diffserv@ietf.org  > > Subject: [Diffserv]
      > CountActTable  >  = > In the lattest DS PIB :  >  > > Quoted from the =
      > draft-ietf-diffserv-pib-03.txt = (page 5) :  > > Action >
      > Tables  > = >      A general extensible framework and = examples of  > >
      > parameterization  > = >      tables for Absolute Drop, Mark and = Count >
      > actions.  >  > = and page 11 :  > > 4.5.1.  DSCP Mark Action PRC  = > > >
      > (...)  > > = 4.5.2.  Absolute Drop Action  >  > So why is there = no Count >
      > Action Table in the PIB ?  = > However there is an CountActTable in the >
      > MIB...I feel  > = confused.  >  > Thanx  >  > -- Yacine = El Mghazli  >  > >
      > = ----------------------------------------------------------------------&n= bsp; >
       >  >   = Alcatel R&I  >   Software and Services Strategic = Program - >
      > VIPeR  >   = Marcoussis, France  >   Tel  +33 1 69 63 41 = 87  >   Fax  +33
      > 1 > 69 63 11 69  = >   yacine.el_mghazli@ms.alcatel.fr  >  > = >
      > = ----------------------------------------------------------------------&n= bsp; >
       >  >  = >  > _______________________________________________  = > diffserv >
      > mailing list  > = diffserv@ietf.org  > >
      > <<http://www1.ietf.org/mailman/listinfo/diffserv>= http://www1.ietf.org/mail
      > man/listinfo/diffserv>http://www1.ietf.org/mailm >
      > an/listinfo/diffserv  > = > Archive:  > >
      > <<http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mailli
      > s>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mailli
      > s >
      > t.h><http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mai
      > l>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mail >
       >  list.h  > = tml  >
      >
      >_______________________________________________ = diffserv mailing
      >list  diffserv@ietf.org =
      ><http://www1.ietf.org/mailman/listinfo/diffserv>= http://www1.ietf.org/mailma
      >n/listinfo/diffserv  = Archive:
      ><http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist
      >.html>http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/mai
      >llist.html


      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_QU4Iq4x0yBw1PfQzKiEL5g)-- From owner-rap@ops.ietf.org Fri Apr 6 14:28:46 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16595 for ; Fri, 6 Apr 2001 14:28:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lawt-000BDH-00 for rap-data@psg.com; Fri, 06 Apr 2001 11:27:07 -0700 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.16 #1) id 14laws-000BBo-00 for rap@ops.ietf.org; Fri, 06 Apr 2001 11:27:06 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id SAA04199; Fri, 6 Apr 2001 18:25:19 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 06 Apr 2001 18:25:18 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2FLLY8V6>; Fri, 6 Apr 2001 11:25:16 -0700 Message-ID: From: "Kulkarni, Amol" To: "'Iliff, Tina'" , "'Joel M. Halpern'" , diffserv@ietf.org, "'rap@ops.ietf.org'" Subject: RE: [Diffserv] CountActTable Date: Fri, 6 Apr 2001 11:25:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BEC6.EC934390" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0BEC6.EC934390 Content-Type: text/plain; charset="iso-8859-1" I'd like to comment that the Accounting Framework does allow one to configure accounting. It is a general framework, which can be applied to any PIB with some small additions. We plan to come up with a draft for Diffserv Accounting based on this framework. Although we haven't started working on it yet, it'll probably be similar to the accounting info in the MIB. In the future PIBs, I would expect accounting PRCs to be included within the PIBs. Here's a link to the accounting framework PIB: http://www.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-01.txt -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Friday, April 06, 2001 10:03 AM To: 'Joel M. Halpern'; diffserv@ietf.org; 'rap@ops.ietf.org' Subject: RE: [Diffserv] CountActTable So, in other words, you are implying that a boolean value should be added to each PIB PRC to specify whether or not to count? I see the use; however, I do not think it is applicable to the Diffserv PIB since a counter is not a specific piece of QoS information. I would recommend adding it to the Framework PIB (for example, add a boolean value to the frwkPrcSupport PRC) if it is added to a PIB at all. Tina Iliff BM__MailData-----Original Message----- From: Joel M. Halpern [ mailto:joel@longsys.com ] Sent: Friday, April 06, 2001 10:00 AM To: diffserv@ietf.org Subject: RE: [Diffserv] CountActTable There are no defined implicit count actions. The point of including the actions explicitily in the MIB / Model (and presumably PIB) is that depending upon the particular usage intended by the administrator, one may want to count at different points. The Count Actions define where counting is done. Yours, Joel M. Halpern At 01:45 PM 4/6/01 +0000, Iliff, Tina wrote: >However, it seems logical that the count action would be implicit and >therefore, does not need configuration parameters within a policy >set. For example, if the Accounting Timer is set, then the PEP should >"turn on" its counters; otherwise, the counters are "disabled". > >Tina Iliff >-----Original Message----- From: Joel M. Halpern >[< mailto:joel@longsys.com > mailto:joel@longsys.com ] Sent: Wednesday, >April 04, 2001 12:14 PM To: diffserv@ietf.org Subject: RE: >[Diffserv] CountActTable > >The Count Action is a diffserv packet handling action. Including it in >a configuration causes counting to be done. It sure seems that this >action ought to be configurable with the PIB, just like every other >Diffserv packet handling action (Meter, Mark, Drop). Otherwise, one would >have to use SNMP to CONFIGURE this element in order to later use SNMP to >retreive the counts. > >This Action is not itself a counter that would go in an Accounting PIB, >or only in an SNMP MIB. > >Yours, Joel M. Halpern > >At 03:13 PM 4/4/01 +0000, Iliff, Tina wrote: > > >Yacine, > >Like I said, it is just an assumption or a guess. Someone > else will have >to answer. The Accounting PIB may be a good place for > a >counter. However, I have not taken a look at that draft in a > while. > >Tina Iliff >-----Original Message----- From: Yacine El > Mghazli > >[<< mailto:yacine.el_mghazli@ms.alcatel.fr > mailto:yacine.el_mghazli@ms.a > lcatel.fr> mailto:yacine.el_mghazli@ms.alcate >l.fr] Sent: Wednesday, > April 04, 2001 10:07 AM To: Iliff, > Tina; >diffserv@ietf.org Subject: Re: [Diffserv] > CountActTable > > > I am just guessing here but it makes more sense to > me to only have a > count > action in the MIB and not in the PIB. I do > not consider > counting of packets > traversing certain datapath > functional elements a > piece of policy; however, > I do consider it as > part of a network nodes > management. > >Do you mean that counting > packets is only managed using SNMP ? > > > Tina Iliff > > > > -----Original Message----- > From: Yacine El > Mghazli > > > [<< mailto:yacine.el_mghazli@alcatel.fr > mailto:yacine.el_mghazli@alcatel.fr > > mailto:yacine.el_mghazli@alcatel.fr ] > > Sent: Wednesday, April 04, > 2001 7:39 AM > To: diffserv@ietf.org > > Subject: [Diffserv] > CountActTable > > In the lattest DS PIB : > > > Quoted from the > draft-ietf-diffserv-pib-03.txt (page 5) : > > Action > > Tables > > A general extensible framework and examples of > > > parameterization > > tables for Absolute Drop, Mark and Count > > actions. > > and page 11 : > > 4.5.1. DSCP Mark Action PRC > > > > (...) > > 4.5.2. Absolute Drop Action > > So why is there no Count > > Action Table in the PIB ? > However there is an CountActTable in the > > MIB...I feel > confused. > > Thanx > > -- Yacine El Mghazli > > > > ---------------------------------------------------------------------- > > > Alcatel R&I > Software and Services Strategic Program - > > VIPeR > Marcoussis, France > Tel +33 1 69 63 41 87 > Fax +33 > 1 > 69 63 11 69 > yacine.el_mghazli@ms.alcatel.fr > > > > ---------------------------------------------------------------------- > > > > > _______________________________________________ > diffserv > > mailing list > diffserv@ietf.org > > > << http://www1.ietf.org/mailman/listinfo/diffserv > http://www1.ietf.org/mail > man/listinfo/diffserv> http://www1.ietf.org/mailm > > an/listinfo/diffserv > > Archive: > > > << http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > s> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > s > > t.h>< http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai > l> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mail > > list.h > tml > > >_______________________________________________ diffserv mailing >list diffserv@ietf.org >< http://www1.ietf.org/mailman/listinfo/diffserv > http://www1.ietf.org/mailma >n/listinfo/diffserv Archive: >< http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist >.html> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mai >llist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C0BEC6.EC934390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] CountActTable
I'd=20 like to comment that the Accounting Framework does allow one to = configure=20 accounting. It is a general framework, which can be applied to any PIB = with some=20 small additions.
 
We=20 plan to come up with a draft for Diffserv Accounting based on this = framework. Although we haven't started working on it yet, it'll = probably be=20 similar to the accounting info in the MIB.
 
In the=20 future PIBs, I would expect accounting PRCs to be included within the=20 PIBs.
 
Here's=20 a link to the accounting framework PIB: http://www.ietf.org/internet-drafts/draft-ietf-rap-acct-fr-pib-01= .txt
-----Original Message-----
From: Iliff, Tina=20 [mailto:Tina.Iliff@WCOM.Com]
Sent: Friday, April 06, 2001 = 10:03=20 AM
To: 'Joel M. Halpern'; diffserv@ietf.org;=20 'rap@ops.ietf.org'
Subject: RE: [Diffserv]=20 CountActTable

So, in other words, you are implying = that a boolean=20 value should be added to each PIB PRC to specify whether or not to=20 count?  I see the use; however, I do not think it is applicable = to the=20 Diffserv PIB since a counter is not a specific piece of QoS = information. =20 I would recommend adding it to the Framework PIB (for example, add a = boolean=20 value to the frwkPrcSupport PRC) if it is added to a PIB at = all.

Tina Iliff =


      -----Original=20 Message-----
      From:  =20 Joel M. Halpern [mailto:joel@longsys.com]= =20
      Sent:   = Friday, April 06, 2001 10:00 AM       =
      To:           = diffserv@ietf.org
      Subject:        = RE: [Diffserv] CountActTable

      There are no defined implicit = count=20 actions.  The point of including the
      actions explicitily in the MIB / Model (and presumably = PIB) is that=20
      depending upon the = particular usage=20 intended by the administrator, one may
      want to count at different points.  The Count = Actions define=20 where counting
      is = done.

      Yours,
      Joel=20 M. Halpern

      At 01:45 PM 4/6/01 +0000, Iliff, = Tina=20 wrote:

      >However, it seems logical that = the count=20 action would be implicit and
      >therefore, does not need configuration parameters = within a=20 policy
      >set.  For = example, if=20 the Accounting Timer is set, then the PEP should
      >"turn on" its counters; otherwise, the = counters are=20 "disabled".
      > =
      >Tina Iliff
      >-----Original Message-----  From:   = Joel M.=20 Halpern
      >[<mailto:joel@longsys.com>mailto:joel@longsys.com] =20 Sent:   Wednesday,
      >April=20 04, 2001 12:14 PM  To:    =20 diffserv@ietf.org  = Subject:       =20 RE:
      >[Diffserv] = CountActTable=20
      >
      >The Count Action is a diffserv packet handling = action. =20 Including it in
      >a =20 configuration causes counting to be done.  It sure seems = that this=20
      >action ought to be = configurable=20 with the PIB, just like every other
      >Diffserv packet handling action (Meter, Mark, = Drop). =20 Otherwise, one would
      >have to use=20 SNMP to CONFIGURE this element in order to later use SNMP to=20
      >retreive the = counts.=20
      >
      >This Action is not itself a counter that would go in = an=20 Accounting PIB,
      >or  only in an=20 SNMP MIB.
      > =
      >Yours,  Joel M. Halpern =
      >
      >At 03:13 PM=20 4/4/01 +0000, Iliff, Tina wrote:
      >
      > = >Yacine, =20 >  >Like I said, it is just an assumption or a = guess. =20 Someone
      > else will = have =20 >to answer.  The Accounting PIB may be a good place for=20
      > a >counter.  = However, I=20 have not taken a look at that draft in a
      > while.  >  >Tina Iliff  = >-----Original=20 Message-----  From:   Yacine El
      > Mghazli
       > =20 >[<<mailto:yacine.el_mghazli= @ms.alcatel.fr>mailto:yacine.el_mghazli@ms.a= =20
      > lcatel.fr>mailto:yacine.el_mghazli@ms.= alcate=20 >l.fr]  Sent:   Wednesday,
      > April 04, 2001 10:07 AM  = To:    =20 Iliff,
      > Tina;=20 >diffserv@ietf.org =20 Subject:        Re: [Diffserv] =
      > CountActTable  = > =20 > > I am just guessing here but it makes more sense to=20
      > me to only have = a  >=20 count  > action in the MIB and not in the PIB.  I do =
      > not consider > = counting=20 of  packets  > traversing certain datapath =
      > functional elements a > piece of = policy; =20 however,  > I do consider it as
      > part of a network nodes > management.  = > =20 >Do you mean that counting
      >=20 packets is only managed using SNMP ?  >  > > = Tina=20 Iliff  >  >  >
      > -----Original Message-----  > From: Yacine = El =20 > Mghazli  > >
      >=20 [<<mailto:yacine.el_mghazli@al= catel.fr>mailto:yacine.el_mghazli@al= catel.fr=20
       > >mailto:yacine.el_mghazli@al= catel.fr] =20 >   > Sent: Wednesday, April 04,
      > 2001 7:39 AM  > To: = diffserv@ietf.org =20 > > Subject: [Diffserv]
      >=20 CountActTable  >  > In the lattest DS PIB :  = >  > > Quoted from the
      > draft-ietf-diffserv-pib-03.txt (page 5) :  = > >=20 Action >
      > = Tables  >=20 >      A general extensible framework = and=20 examples of  > >
      >=20 parameterization  > >      = tables for=20 Absolute Drop, Mark and Count >
      >=20 actions.  >  > and page 11 :  > > = 4.5.1. =20 DSCP Mark Action PRC  > > >
      > (...)  > > 4.5.2.  Absolute Drop = Action =20 >  > So why is there no Count >
      > Action Table in the PIB ?  > However there = is an=20 CountActTable in the >
      > MIB...I=20 feel  > confused.  >  > Thanx  = > =20 > -- Yacine El Mghazli  >  > > =
      >=20 = ----------------------------------------------------------------------&n= bsp;=20 >
       >  = >  =20 Alcatel R&I  >   Software and Services = Strategic=20 Program - >
      > = VIPeR =20 >   Marcoussis, France  >   = Tel  +33 1=20 69 63 41 87  >   Fax  +33
      > 1 > 69 63 11 69  = >  =20 yacine.el_mghazli@ms.alcatel.fr  >  > >=20
      >=20 = ----------------------------------------------------------------------&n= bsp;=20 >
       >  = > =20 >  > = _______________________________________________  >=20 diffserv >
      > mailing = list =20 > diffserv@ietf.org  > >
      > <<http://www1.ietf.org/mailman/listinfo/diffserv>http://www1.ietf.org/mail
      > man/listinfo/diffserv>http://www1.ietf.org/mailm > =
      > an/listinfo/diffserv  > > = Archive: =20 > >
      > <<http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mailli=20
      > s>http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mailli=20
      > s > =
      > t.h><http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mai=20
      > l>http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mail=20 >
       >  = list.h  >=20 tml  >
      > =
      >_______________________________________________  = diffserv=20 mailing
      >list =20 diffserv@ietf.org
      ><http://www1.ietf.org/mailman/listinfo/diffserv>http://www1.ietf.org/mailma
      >n/listinfo/diffserv  Archive:
      ><http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/maillist=20
      >.html>http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/mai=20
      >llist.html =


      _______________________________________________ =
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv=20
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffser= v/current/maillist.html=20

------_=_NextPart_001_01C0BEC6.EC934390-- From owner-rap@ops.ietf.org Fri Apr 6 16:22:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19466 for ; Fri, 6 Apr 2001 16:22:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lcjT-000Fs7-00 for rap-data@psg.com; Fri, 06 Apr 2001 13:21:23 -0700 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by psg.com with esmtp (Exim 3.16 #1) id 14lcjS-000Fra-00 for rap@ops.ietf.org; Fri, 06 Apr 2001 13:21:22 -0700 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Fri, 6 Apr 2001 16:20:31 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6KGZAF; Fri, 6 Apr 2001 16:20:30 -0400 Received: from tweedy (dhcp223-130.engeast.baynetworks.com [192.32.223.130]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWR5VG; Fri, 6 Apr 2001 16:20:29 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 06 Apr 2001 16:19:42 -0400 To: "Iliff, Tina" X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: RE: [Diffserv] CountActTable Cc: "'Moisand, Jerome'" , "'Yacine El Mghazli'" , rap@ops.ietf.org, "Rawlins, Diana" , "Joel M. Halpern" , Brian E Carpenter In-Reply-To: <492EB4A3F68CD411ABE800508B69362E3F56DA@RIPEXCH002.wcomnet. com> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Orig: Message-Id: Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I have posted the following on the DiffServ list also.
Please skip if you read it on the DiffServ list first.

And I am glad we have agreements.

Yes, currently work is under way for a QoS Accounting Policy PIB
(not exact or finalized name, so please don't comment on the name :)).
separate from the Accounting Framework PIB.
This will include capability of where statistics can be gathered (different
device put counters in different ASICs of different QoS datapaths),=20
where statistics need to be gathered (as determined by the PDP),
and what statistics need to be gathered.
Please note the statistics discussed here are relavant to a specific
policy instance at the PEP.
Please also note this PIB does not intended to indicate how the statistics
will be used. Billing and other applications are considered application
layers above the PDP that does not need to be indicated in the information
exchanged between the PDP and PEP.
Hope this clear some of air up.
-- Kwok Ho Chan --


At 08:35 PM 4/5/01 +0000, Iliff, Tina wrote:

Agree.=
Tina Iliff
      -----Original Message----- From:=A0=A0 Moisand, Jerome [mailto:jmoisand@unispherenet= works.com] Sent:=A0=A0 Thursday, April= 05, 2001 3:23 PM To:=A0=A0=A0=A0 'Yacine El= Mghazli'; rap@ops.ietf.org; Rawlins, Diana= Cc:=A0=A0=A0=A0 Iliff, Tina;= Joel M. Halpern; Brian E Carpenter Subject:=A0=A0=A0=A0=A0=A0=A0 RE: [Diffserv] CountActTable

      Speaking for my company, yes we feel it is very important to have= such counters via COPS reports. Because SNMP is not a very scalable way to get counters on a large number= of objects (e.g. IP interfaces which may be as numerous as tens of thousands= or more on a given box) in a reliable way. I hope I will not get flamed= for this statement!=A0 ;-)

      Plus differentiated services typically come with differentiated= charging models (and some of these billing models might be based on volume). So it= is key to get service usage (aka accounting) data in association with= Diffserv policies. And in a reliable/scalable way.

      This being said, based on the accounting framework currently defined in= the "rap" group, accounting PIBs are clearly separate from the= related "provisioning" PIB. And related objects (e.g. classifiers &= meters) are referenced via pointers.

      So it makes sense to not have counters in the Diffserv PIB. As long as= there is a "Diffserv accounting PIB" in the works (or the general one= described in the accounting framework is applicable). Jerome

      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Jerome P. Moisand Senior Product Manager Unisphere Networks One Executive Drive=A0 Chelmsford, MA 01824= Tel: 978-848-0648=A0 Fax: 978-848-0399 mailto:jmoisand@UnisphereNet= works.com



      -----Original Message----- From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms= .alcatel.fr] Sent: Thursday, April 05, 2001 4:57 AM To: rap@ops.ietf.org; Rawlins, Diana Cc: Iliff, Tina; Joel M. Halpern; Brian E Carpenter= Subject: Re: [Diffserv] CountActTable

      In the framework of COPS-PR configuration, is it important to be able= to install/remove/report counters via the DiffServ PIB ? What do think= people involved with the accounting PIB ? To my mind I hardly understand why one could not install a counter= with COPS-PR in order to monitor it by SNMP, or even to report it via= COPS-PR... I'm also interested in the reasons which made DS PIB authors remove= the CountActTable from the PIB... I guess they must have good ones !

      Thanks Yacine

      ----- Original Message ----- From: "Brian E Carpenter"= <brian@hursley.ibm.com> To: "Iliff, Tina" <Tina.Iliff@WCOM.Com> Cc: <diffserv@ietf.org> Sent: Wednesday, April 04, 2001 9:25 PM Subject: Re: [Diffserv] CountActTable

      > I don't see the issue for the MIB: it does have counters and nobody= is > proposing to take them away. If you want counters in the PIB,= now > is the time to say so since there will be a new version very= soon. > The model isn't going to answer that question for you. > >=A0=A0=A0 Brian > > > "Iliff, Tina" wrote: > > > > Here are some excerpts from diffserv-model-06: > > > > At the lowest level considered here, are individual functional= datapath elements, each with their own configuration parameters= > > and management counters and flags.= > > > > using a Counter element downstream of the Meter, it might also be= used to help in collecting data for out-of-band management= > > functions such as billing applications.= > > > > I find these excerpts unclear as to determining if a PIB or MIB or= both should implement a data structure to support the= > > definition of a Counter Action. > > > > Tina Iliff > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -----Original= Message----- > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 From:=A0=A0 Joel M. Halpern [mailto:joel@longsys.com] > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Sent:=A0=A0 Wednesday, April 04,= 2001 12:14 PM > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 To:=A0=A0=A0=A0= diffserv@ietf.org > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Subject:=A0=A0=A0=A0=A0=A0=A0 RE:= [Diffserv] CountActTable > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The Count Action is a diffserv= packet handling action. Including it in a > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 configuration causes counting to be= done.=A0 It sure seems that this action > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ought to be configurable with the= PIB, just like every other Diffserv > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 packet handling action (Meter, Mark,= Drop).=A0 Otherwise, one would have to > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 use SNMP to CONFIGURE this element= in order to later use SNMP to retreive > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the counts.= > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This Action is not itself a counter= that would go in an Accounting PIB, or > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 only in an SNMP MIB. > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yours,= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Joel M. Halpern > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 At 03:13 PM 4/4/01 +0000, Iliff,= Tina wrote: > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >Yacine,= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >Like I said, it is just an= assumption or a guess.=A0 Someone else will have > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >to answer.=A0 The Accounting PIB= may be a good place for a > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >counter.=A0 However, I have not= taken a look at that draft in a while. > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >Tina Iliff= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >-----Original Message-----=A0= From:=A0=A0 Yacine El Mghazli > > >[<mailto:yacine.el_mghazli@ms= .alcatel.fr>mailto:yacine.el_mghazli@ms.alc= ate > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >l.fr]=A0 Sent:=A0=A0 Wednesday,= April 04, 2001 10:07 AM=A0 To: Iliff, Tina; > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >diffserv@ietf.org=A0= Subject:=A0=A0=A0=A0=A0=A0=A0 Re: [Diffserv]= CountActTable > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > > I am just guessing here= but it makes more sense to me to only have a > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > count=A0 > action in the MIB= and not in the PIB.=A0 I do not consider > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > counting of=A0 packets=A0 >= traversing certain datapath functional elements a > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > piece of policy;=A0 however,=A0= > I do consider it as part of a network nodes > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > management. > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >Do you mean that counting= packets is only managed using SNMP ? > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >= > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > > Tina Iliff=A0 >=A0= >=A0 > -----Original Message-----=A0 > From:= Yacine El > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > Mghazli=A0 > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >= [<mailto:yacine.el_mghazli@alcat= el.fr>mailto:yacine.el_mghazli@alcat= el.fr] > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=A0=A0 > Sent: Wednesday,= April 04, 2001 7:39 AM=A0 > To: diffserv@ietf.org=A0 > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > Subject: [Diffserv]= CountActTable=A0 >=A0 > In the lattest DS= PIB :=A0 >=A0 > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > Quoted from the= draft-ietf-diffserv-pib-03.txt (page 5) :=A0 >= > Action > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > Tables=A0 > >=A0=A0=A0=A0= =A0 A general extensible framework and examples= of=A0 > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > parameterization=A0 >= >=A0=A0=A0=A0=A0 tables for Absolute Drop, Mark= and Count > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > actions.=A0 >=A0 > and= page 11 :=A0 > > 4.5.1.=A0 DSCP Mark Action= PRC=A0 > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > (...)=A0 > > 4.5.2.=A0= Absolute Drop Action=A0 >=A0 > So why is= there no Count > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > Action Table in the PIB ?=A0= > However there is an CountActTable in the > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > MIB...I feel=A0 > confused.= =A0 >=A0 > Thanx=A0 >=A0 > -- Yacine El= Mghazli=A0 >=A0 > > >









      =A0=A0=A0 >= ---------------------------------------------------------------------- > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=A0=A0 Alcatel R&I=A0= >=A0=A0 Software and Services Strategic= Program - > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > VIPeR=A0 >=A0=A0 Marcoussis,= France=A0 >=A0=A0 Tel=A0 +33 1 69 63 41 87=A0 >= Fax=A0 +33 1 > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > 69 63 11 69=A0 >=A0=A0= yacine.el_mghazli@ms.alcatel.fr=A0 >=A0 >= > >









      =A0=A0=A0 >= ---------------------------------------------------------------------- > > > _______________________________________________= > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.or= g/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current= /maillist.h tml >=20


From owner-rap@ops.ietf.org Sat Apr 7 08:11:10 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13635 for ; Sat, 7 Apr 2001 08:11:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lrXZ-0003IZ-00 for rap-data@psg.com; Sat, 07 Apr 2001 05:10:05 -0700 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.16 #1) id 14lrXY-0003IE-00 for rap@ops.ietf.org; Sat, 07 Apr 2001 05:10:04 -0700 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA07521 for ; Sat, 7 Apr 2001 08:10:03 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA06551 for ; Sat, 7 Apr 2001 08:08:18 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Apr 2001 14:08:17 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0BEE842E@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: rap Subject: RAP re-charter Date: Sat, 7 Apr 2001 14:08:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk The IESG has decided to send out the new charter to IETF-Announce list for people to review and give feedback if any. Hopefully we cann approve the new charter in our next IESG get-together on April 19th. Bert From owner-rap@ops.ietf.org Mon Apr 9 12:50:27 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11539 for ; Mon, 9 Apr 2001 12:50:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mepr-0001iO-00 for rap-data@psg.com; Mon, 09 Apr 2001 09:48:15 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.16 #1) id 14mepo-0001iG-00 for rap@ops.ietf.org; Mon, 09 Apr 2001 09:48:13 -0700 Received: from hdcvwall.wipsys.stph.net (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id WAA11063 for ; Mon, 9 Apr 2001 22:19:35 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GBJAQJ00.1S6 for ; Mon, 9 Apr 2001 22:19:31 +0530 Message-ID: <3AD1E673.B69B2706@wipro.com> Date: Mon, 09 Apr 2001 22:12:27 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF RAP WG Subject: malformed messages from client Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, If a malformed OPN/REQ message is received at COPS server, server can handle it by informing client about the error using CC/DEC respectively. What is the expected behavior if COPS server receives a malformed CC/DRQ/SSC/KA message? regards kp -- Krishna Prasad.Akkineni WIPRO Technologies, ---------------------------------------------------- The opinions expressed here are my personal opinions and not necessarily those of WIPRO Technologies. ---------------------------------------------------- From owner-rap@ops.ietf.org Mon Apr 9 13:24:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12307 for ; Mon, 9 Apr 2001 13:24:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mfMx-0002TC-00 for rap-data@psg.com; Mon, 09 Apr 2001 10:22:27 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14mfMw-0002Rr-00 for rap@ops.ietf.org; Mon, 09 Apr 2001 10:22:26 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GBJ00MQ5C6AA1@firewall.mcit.com> for rap@ops.ietf.org; Mon, 9 Apr 2001 17:20:34 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBJ00H01C66EX@dgismtp02.wcomnet.com>; Mon, 09 Apr 2001 17:20:33 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBJ00EFWC5SJC@dgismtp02.wcomnet.com>; Mon, 09 Apr 2001 17:20:16 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Mon, 09 Apr 2001 17:20:16 +0000 Content-return: allowed Date: Mon, 09 Apr 2001 17:20:09 +0000 From: "Iliff, Tina" Subject: RE: malformed messages from client To: "'Krishna Prasad Akkineni'" , IETF RAP WG Message-id: <492EB4A3F68CD411ABE800508B69362E3F56F6@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_XvUN0eudE/D5JsilkbD0eA)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_XvUN0eudE/D5JsilkbD0eA) Content-type: text/plain; charset=ISO-8859-1 Krishna, That is an implementation question. There are not any specific protocol requirements defined. Tina Iliff -----Original Message----- From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com] Sent: Monday, April 09, 2001 11:42 AM To: IETF RAP WG Subject: malformed messages from client Hi, If a malformed OPN/REQ message is received at COPS server, server can handle it by informing client about the error using CC/DEC respectively. What is the expected behavior if COPS server receives a malformed CC/DRQ/SSC/KA message? regards kp -- Krishna Prasad.Akkineni WIPRO Technologies, ---------------------------------------------------- The opinions expressed here are my personal opinions and not necessarily those of WIPRO Technologies. ---------------------------------------------------- --Boundary_(ID_XvUN0eudE/D5JsilkbD0eA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: malformed messages from client

Krishna,

That is an implementation = question.  There are not any specific protocol requirements = defined.
Tina Iliff


      -----Original = Message-----
      From:   Krishna Prasad = Akkineni [mailto:krishna.akkineni@wipro= .com]
      Sent:   Monday, April 09, 2001 11:42 AM
      To:     IETF RAP WG
      Subject:       = malformed messages from = client

      Hi,
        If a malformed OPN/REQ message = is received at COPS
        server, server can handle it = by informing client about the error
        using CC/DEC respectively. =
        What is the expected behavior = if
        COPS server receives a = malformed CC/DRQ/SSC/KA
        message?
      regards
      kp
      --
      Krishna Prasad.Akkineni
      WIPRO Technologies,
      ----------------------------------------------------
      The opinions expressed here are my = personal opinions
      and not necessarily those of WIPRO = Technologies.
      ----------------------------------------------------

--Boundary_(ID_XvUN0eudE/D5JsilkbD0eA)-- From owner-rap@ops.ietf.org Thu Apr 12 17:18:33 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11233 for ; Thu, 12 Apr 2001 17:18:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14noS3-0001Oh-00 for rap-data@psg.com; Thu, 12 Apr 2001 14:16:27 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14noS2-0001Mv-00 for rap@ops.ietf.org; Thu, 12 Apr 2001 14:16:26 -0700 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GBP00CG671F03@firewall.mcit.com> for rap@ops.ietf.org; Thu, 12 Apr 2001 21:15:16 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GBP0050171C0O@pmismtp01.wcomnet.com> for rap@ops.ietf.org; Thu, 12 Apr 2001 21:15:15 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GBP003827116S@pmismtp01.wcomnet.com> for rap@ops.ietf.org; Thu, 12 Apr 2001 21:15:01 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 21:15:01 +0000 Content-return: allowed Date: Thu, 12 Apr 2001 21:14:59 +0000 From: "Iliff, Tina" Subject: COPS-PR DEC NamedClientSI object and framework-pib-04 Notify PRCs To: "'rap@ops.ietf.org'" Cc: "Sunlin, Richard (c)" , "Rawlins, Diana" Message-id: <492EB4A3F68CD411ABE800508B69362E3F572B@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_SNNG70GMEs1D4fEUUmwllA)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_SNNG70GMEs1D4fEUUmwllA) Content-type: text/plain; charset=iso-8859-1 All, I need a little clarification on a certain topic: The COPS-PR NamedClientSI object. Here is an excerpt from COPS-PR RFC 3084: The REQ from a policy provisioning client contains a COPS 'Configuration Request' context object and, optionally, any relevant named client specific information from the PEP. Now, here is an excerpt from framework-pib-04: The PIB indicates which capabilities the PEP must report to the PDP by means of the PIB-ACCESS clause as described in [SPPI]. Now, should the "must" in the framework-pib-04 be removed? I am currently interpreting this excerpt to mean that the PDP MUST expect all Notify PRCs in the NamedClientSI objects. However, RFC 3084 states that the NamedClientSI is optional and that a REQ may include 0 or more of these objects. Another question: Should a PDP send a DEC Null if no NamedClientSI objects are encapsulated in the REQ or should defaults be assumed or is that an implementation choice? Tina Iliff --Boundary_(ID_SNNG70GMEs1D4fEUUmwllA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable COPS-PR DEC NamedClientSI object and framework-pib-04 Notify = PRCs

All,

I need a little clarification on a = certain topic:  The COPS-PR NamedClientSI object.  Here is an = excerpt from COPS-PR RFC 3084:

The REQ from a policy = provisioning client contains a COPS
'Configuration Request' context = object and, optionally, any relevant named client specific information = from the PEP.

Now, here is an excerpt from = framework-pib-04:
The PIB indicates which = capabilities the PEP must report to the PDP by means of the PIB-ACCESS = clause as described in [SPPI].

Now, should the "must" in the framework-pib-04 = be removed?  I am currently interpreting this excerpt to mean that = the PDP MUST expect all Notify PRCs in the NamedClientSI objects.  = However, RFC 3084 states that the NamedClientSI is optional and that a = REQ may include 0 or more of these objects. 

Another question:  Should a PDP send a DEC = Null if no NamedClientSI objects are encapsulated in the REQ or should = defaults be assumed or is that an implementation choice?

Tina Iliff

--Boundary_(ID_SNNG70GMEs1D4fEUUmwllA)-- From owner-rap@ops.ietf.org Thu Apr 12 18:14:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12185 for ; Thu, 12 Apr 2001 18:14:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14npKI-00033Z-00 for rap-data@psg.com; Thu, 12 Apr 2001 15:12:30 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14npKG-000339-00 for rap@ops.ietf.org; Thu, 12 Apr 2001 15:12:29 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GBP00BAW9MUWQ@firewall.mcit.com> for rap@ops.ietf.org; Thu, 12 Apr 2001 22:11:18 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBP00G019MP6V@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Thu, 12 Apr 2001 22:11:18 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBP00CFN9MLLY@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Thu, 12 Apr 2001 22:11:10 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 22:11:09 +0000 Content-return: allowed Date: Thu, 12 Apr 2001 22:11:07 +0000 From: "Iliff, Tina" Subject: RE: COPS-PR DEC NamedClientSI object and framework-pib-04 Notify PRCs To: "'rap@ops.ietf.org'" Cc: "Sunlin, Richard (c)" , "Rawlins, Diana" Message-id: <492EB4A3F68CD411ABE800508B69362E3F572C@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_D2LiVU0zQX+usP0Ry4/xCw)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_D2LiVU0zQX+usP0Ry4/xCw) Content-type: text/plain; charset=ISO-8859-1 An addition to the excerpts and questions in the below e-mail: Here is an excerpt from draft-ietf-rap-sppi-05: - the value "install" is used to indicate a PRC which a PDP can install in the PEP as provisioning information. - the value "notify" is used to indicate a PRC for which the PEP must notify the PDP of all its instances and attribute values of that PRC. - - the value "install-notify" is used to indicate the uncommon type of PRC which has both characteristics: "install" and "notify". The framework-pib-04 draft does reference this draft. This draft also uses the word "must" for the PIB-ACCESS value of "notify". Should there be a bis for RFC3084 to specify that for Client-Type of 2 the NamedClientSI object is mandatory or should it be mandatory for all COPS-PR Client Types? Regards, Tina Iliff -----Original Message----- From: Iliff, Tina Sent: Thursday, April 12, 2001 4:15 PM To: 'rap@ops.ietf.org' Cc: Sunlin, Richard (c); Rawlins, Diana Subject: COPS-PR DEC NamedClientSI object and framework-pib-04 Notify PRCs All, I need a little clarification on a certain topic: The COPS-PR NamedClientSI object. Here is an excerpt from COPS-PR RFC 3084: The REQ from a policy provisioning client contains a COPS 'Configuration Request' context object and, optionally, any relevant named client specific information from the PEP. Now, here is an excerpt from framework-pib-04: The PIB indicates which capabilities the PEP must report to the PDP by means of the PIB-ACCESS clause as described in [SPPI]. Now, should the "must" in the framework-pib-04 be removed? I am currently interpreting this excerpt to mean that the PDP MUST expect all Notify PRCs in the NamedClientSI objects. However, RFC 3084 states that the NamedClientSI is optional and that a REQ may include 0 or more of these objects. Another question: Should a PDP send a DEC Null if no NamedClientSI objects are encapsulated in the REQ or should defaults be assumed or is that an implementation choice? Tina Iliff --Boundary_(ID_D2LiVU0zQX+usP0Ry4/xCw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: COPS-PR DEC NamedClientSI object and framework-pib-04 Notify = PRCs

An addition to the excerpts and = questions in the below e-mail:

Here is an excerpt from = draft-ietf-rap-sppi-05:

-   the value "install" is used to indicate a PRC = which a PDP can install in the PEP as provisioning information.=20

  • the value "notify" is = used to indicate a PRC for which the PEP must notify the PDP of all its = instances and attribute values of that PRC.
  •  - the value = "install-notify" is used to indicate the uncommon type of PRC = which has both characteristics: "install" and = "notify".

The framework-pib-04 draft does = reference this draft.  This draft also uses the word "must" for = the PIB-ACCESS value of "notify".  Should there be a bis for = RFC3084 to specify that for Client-Type of 2 the NamedClientSI object = is mandatory or should it be mandatory for all COPS-PR Client = Types?

Regards,
Tina Iliff


      -----Original = Message-----
      From:   Iliff, Tina =
      Sent:   Thursday, April 12, 2001 4:15 PM
      To:     'rap@ops.ietf.org'
      Cc:     Sunlin, Richard (c); Rawlins, Diana
      Subject:       = COPS-PR DEC NamedClientSI object and = framework-pib-04 Notify PRCs

      All,

      I need a little clarification on a = certain topic:  The COPS-PR NamedClientSI object.  Here is an = excerpt from COPS-PR RFC 3084:

      The REQ from a policy = provisioning client contains a COPS
      'Configuration Request' context = object and, optionally, any relevant named client specific information = from the PEP.

      Now, here is an excerpt from = framework-pib-04:
      The PIB indicates which = capabilities the PEP must report to the PDP by means of the PIB-ACCESS = clause as described in [SPPI].

      Now, should the "must" in the framework-pib-04 = be removed?  I am currently interpreting this excerpt to mean that = the PDP MUST expect all Notify PRCs in the NamedClientSI objects.  = However, RFC 3084 states that the NamedClientSI is optional and that a = REQ may include 0 or more of these objects. 

      Another question:  Should a PDP send a DEC = Null if no NamedClientSI objects are encapsulated in the REQ or should = defaults be assumed or is that an implementation choice?

      Tina Iliff

--Boundary_(ID_D2LiVU0zQX+usP0Ry4/xCw)-- From owner-rap@ops.ietf.org Thu Apr 12 19:07:53 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13201 for ; Thu, 12 Apr 2001 19:07:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nqA0-00041Y-00 for rap-data@psg.com; Thu, 12 Apr 2001 16:05:56 -0700 Received: from mail4.galactica.it ([212.41.208.21] helo=galactica.it) by psg.com with esmtp (Exim 3.16 #1) id 14nq9z-00041P-00 for rap@ops.ietf.org; Thu, 12 Apr 2001 16:05:55 -0700 Received: from MORDICCHIO ([62.122.23.164]) by galactica.it with Microsoft SMTPSVC(5.5.1877.537.53); Fri, 13 Apr 2001 01:04:50 +0200 Message-ID: <006b01c0c3a5$2f966720$a4177a3e@MORDICCHIO> From: "Vito Pinto" To: Date: Thu, 12 Apr 2001 19:54:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA13201 Hi, I have a little question about PIBs used in COPS-PR: there are some native/specialized tools to edit/create them? I think it is possible to reuse all the tools developed from the SNMP community, but there is something built thinking about COPS-PR? Regards Vito Pinto From owner-rap@ops.ietf.org Thu Apr 12 21:52:59 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15786 for ; Thu, 12 Apr 2001 21:52:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nskG-000893-00 for rap-data@psg.com; Thu, 12 Apr 2001 18:51:32 -0700 Received: from jffdns02.or.intel.com ([134.134.248.4] helo=hebe.or.intel.com) by psg.com with esmtp (Exim 3.16 #1) id 14nskF-00088x-00 for rap@ops.ietf.org; Thu, 12 Apr 2001 18:51:31 -0700 Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id BAA09397 for ; Fri, 13 Apr 2001 01:51:30 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Apr 2001 01:51:30 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id <2TS6T161>; Thu, 12 Apr 2001 18:51:28 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E89006B17CD0@orsmsx35.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org Subject: PRC attribute limitation in SPPI Date: Thu, 12 Apr 2001 18:50:27 -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 We have received a lot of good feedback on the SPPI draft as a result of the IESG review and one minor issue came out that we have addressed in the document (draft-ietf-rap-sppi-06.txt). Section 7.1.8 now states: 7.1.8. Provisioning Classes The operations (on PIBs) supported by the SPPI apply exclusively to PRCs. Each PRC is modeled as a tabular structure, i.e., a table. Each instance of a particular PRC has the same set of attributes. The set of attributes which belong to every instance of a particular PRC is modeled as a row in the table. Note that a PRC must have no more than 127 attributes. The usage of subids (for PRC attributes) beyond 127 (that is 128 and above) is reserved for Mapping PIBs to MIBs (see Appendix A). PRCs that require more than 127 attributes must use the AUGMENTS clause to augment the PRC containing the initial 127 attributes to add additional attributes. This limits a specific PRC table to 127 columns. If a PRC contains more than 127 columns it must be broken up into two tables with the second table AUGMENTing the first. I would like to ask people to speak up within a week if they have a serious issue with the limitation. Thanks. -Scott From owner-rap@ops.ietf.org Mon Apr 16 11:39:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06753 for ; Mon, 16 Apr 2001 11:39:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p9am-0008Gn-00 for rap-data@psg.com; Mon, 16 Apr 2001 07:03:00 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14p9al-0008Gg-00 for rap@ops.ietf.org; Mon, 16 Apr 2001 07:02:59 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03881; Mon, 16 Apr 2001 10:02:55 -0400 (EDT) Message-Id: <200104161402.KAA03881@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-sppi-06.txt Date: Mon, 16 Apr 2001 10:02:55 -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 : Structure of Policy Provisioning Information (SPPI) Author(s) : K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-sppi-06.txt Pages : 44 Date : 13-Apr-01 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in RFC 3084 [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-06.txt 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-sppi-06.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-sppi-06.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: <20010413122132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-sppi-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-sppi-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010413122132.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue Apr 17 08:54:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06488 for ; Tue, 17 Apr 2001 08:54:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pUxP-0000AV-00 for rap-data@psg.com; Tue, 17 Apr 2001 05:51:47 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.16 #1) id 14pUxN-0000AJ-00 for rap@ops.ietf.org; Tue, 17 Apr 2001 05:51:46 -0700 Received: from hdcvwall.wipsys.stph.net (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id NAA08319 for ; Tue, 17 Apr 2001 13:49:46 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GBXGG700.7F9 for ; Tue, 17 Apr 2001 13:49:19 +0530 Message-ID: <3ADBFAFA.6CA30731@wipro.com> Date: Tue, 17 Apr 2001 13:42:42 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF RAP WG Subject: multiple context flags incase of PATH message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Is it valid to have multiple context flags in the following Scenario? COPS Client type : RSVP COPS message : REQ M-Type in Context : PATH Following text is an excerpt from RFC2749,section 3.6: ---------- a. Multiple context flags can be set only in two generic cases, which represent a substantial portion of expected COPS transactions, and can be guaranteed not to cause ambiguity. Unicast FF: [Incoming + Allocation + Outgoing] Multicast with only one Resv message received on the interface [Incoming + Allocation] ----------- Both the two generic cases in the above mentioned excerpt from RFC relate with RSVP Resv message only. Can we set multiple context flags incase of PATH message?. If no, then section 5.1 of RFC2749 gave following example where multiple contexts (in&out) are set for PATH message. Could any one please explain this apparent contradiction between the two excerpts mentioned. Excerpt from RFC2749, section 5.1: -------- A Path message arrives from S1: PEP --> PDP REQ := PDP --> PEP DEC := --------- Thnaks Krishna ---------------------------------------------------- The opinions expressed here are my personal opinions and not necessarily those of WIPRO Technologies. ---------------------------------------------------- From owner-rap@ops.ietf.org Tue Apr 17 19:08:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17799 for ; Tue, 17 Apr 2001 19:08:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14peCB-000EAT-00 for rap-data@psg.com; Tue, 17 Apr 2001 15:43:39 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14peCA-000EA8-00 for rap@ops.ietf.org; Tue, 17 Apr 2001 15:43:38 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GBY0075BKFVCI@firewall.mcit.com> for rap@ops.ietf.org; Tue, 17 Apr 2001 22:43:07 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBY00301KFV3P@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Tue, 17 Apr 2001 22:43:07 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBY00KE6KFFZQ@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Tue, 17 Apr 2001 22:42:52 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Apr 2001 22:42:51 +0000 Content-return: allowed Date: Tue, 17 Apr 2001 22:42:49 +0000 From: "Iliff, Tina" Subject: framework-pib-04: Pib Incarnations "Activation" and "De-activati on" Clarification Needed To: "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F574F@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_Fsfze1yaGCeCTbZJzYVJyQ)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Fsfze1yaGCeCTbZJzYVJyQ) Content-type: text/plain; charset=ISO-8859-1 All, One item in the framework-pib-04 draft seems a little ambiguous to me. Please let me know if I am missing something. Specifically, how should one interpret the below RFC 3084 excerpts regarding Pib Incarnations: Multiple PIB Instances [COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy. The intent is to allow for the pre-provisioning of policy that can then be made active by a single, short decision from the PDP. A COPS context can be defined as an independent COPS request state for a particular subject category (client-type). With the COPS-PR protocol, each of these states is identified by a unique client handle. The creation and deletion of these PIB instances is controlled by the PDP as described in [COPS-PR]. Although many PIB instances may be configured on a device (the maximum number of these instances being determined by the device itself) only one of them can be active at any given time, the active one being selected by the PDP. To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance the active one and, similarly, to report the active PIB instance to the PDP in a COPS request message. This attribute is in the Incarnation Table described below. Setting the attribute frwkPibIncarnationActive to 'true' in one PIB instance MUST ensure that the attribute is 'false' in all other contexts. frwkPibIncarnationActive OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "If this attribute is set to TRUE, then the PIB instance to which this PRI belongs becomes the active PIB instance. The previous active instance MUST become inactive and the frwkPibIncarnationActive attribute in that PIB instance MUST be set to false." Specifically, based on this excerpt which endpoint (PEP or PDP) is responsible for setting a Pib Incarnation to "inactive"; i.e. setting its Active attribute to 'False'? It explicitly states that the PDP is responsible for selecting the Active incarnation. My interpretation is that all policy will be sent and indicated as inactive, then the PDP will send just a frwkPibIncarnation instance to "activate" one incarnation identified by its Id. However, who is responsible for "de-activating" currently installed "activated" policy when a new incarnation is sent by the PDP with the Active attribute set to 'True'? Also, please let me know if I am interpreting words incorrectly. Regards, Tina Iliff --Boundary_(ID_Fsfze1yaGCeCTbZJzYVJyQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable framework-pib-04: Pib Incarnations "Activation" and = "De-activation" Clarification Needed

All,

One item in the framework-pib-04 draft = seems a little ambiguous to me.  Please let me know if I am = missing something.  Specifically, how should = one interpret the below RFC 3084 = excerpts regarding Pib Incarnations:

Multiple PIB Instances
   
   [COPS-PR] supports = multiple, disjoint, independent instances of the
   PIB to represent = multiple instances of configured policy.  The
   intent is to allow = for the pre-provisioning of policy that can then
   be made active by = a single, short decision from the PDP.
   
   A COPS context can = be defined as an independent COPS request state
   for a particular = subject category (client-type). 
 
   With the COPS-PR = protocol, each of these states is identified by a
   unique client = handle.  The creation and deletion of these PIB
   instances is = controlled by the PDP as described in [COPS-PR].
   
   Although many PIB = instances may be configured on a device (the
   maximum number of = these instances being determined by the device
   itself) only one = of them can be active at any given time, the active
   one being selected = by the PDP.  To facilitate this selection, the
   Framework PIB = supports an attribute to make a PIB instance the
   active one and, = similarly, to report the active PIB instance to the
 
   PDP in a COPS = request message. This attribute is in the Incarnation
   Table described = below.
   
   Setting the = attribute frwkPibIncarnationActive to 'true' in one PIB
   instance MUST = ensure that the attribute is 'false' in all other
   contexts.

frwkPibIncarnationActive = OBJECT-TYPE
       = SYNTAX         TruthValue =
       = STATUS         current
       DESCRIPTION
           = "If this attribute is set to TRUE, then the PIB instance
           to = which this PRI belongs becomes the active PIB instance.
           The = previous active instance MUST become inactive and the
           = frwkPibIncarnationActive attribute in that PIB instance 
           MUST = be set to false."

Specifically, based on this excerpt = which endpoint (PEP or PDP) is responsible for setting a Pib = Incarnation to "inactive"; i.e. = setting its Active attribute to 'False'?  It explicitly states that the PDP is responsible = for selecting the Active incarnation.  My interpretation is that = all policy will be sent and indicated as inactive, then the PDP will = send just a frwkPibIncarnation instance to "activate" one incarnation = identified by its Id.  However, who is responsible for = "de-activating" currently installed "activated" policy when a new = incarnation is sent by the PDP with the Active attribute set to = 'True'?

Also, please let me know if I am = interpreting words incorrectly.

Regards,
Tina Iliff

--Boundary_(ID_Fsfze1yaGCeCTbZJzYVJyQ)-- From owner-rap@ops.ietf.org Wed Apr 18 14:44:40 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15612 for ; Wed, 18 Apr 2001 14:44:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14puEI-0000cc-00 for rap-data@psg.com; Wed, 18 Apr 2001 08:50:54 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14puEH-0000bg-00 for rap@ops.ietf.org; Wed, 18 Apr 2001 08:50:53 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GBZ0020IVVJ5I@firewall.mcit.com> for rap@ops.ietf.org; Wed, 18 Apr 2001 15:47:43 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBZ00901VUXHR@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Wed, 18 Apr 2001 15:47:43 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBZ00902VUPCH@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Wed, 18 Apr 2001 15:47:15 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 15:47:13 +0000 Content-return: allowed Date: Wed, 18 Apr 2001 15:47:10 +0000 From: "Iliff, Tina" Subject: RE: COPS-PR DEC NamedClientSI object and framework-pib-04 Notify PRCs To: "Iliff, Tina" , "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F5757@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_f5/a2lXw3CHgJbSOrEja7w)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_f5/a2lXw3CHgJbSOrEja7w) Content-type: text/plain; charset=ISO-8859-1 Tina Iliff MCIWorldCom ENSD (972)729-1620 -----Original Message----- From: Iliff, Tina Sent: Thursday, April 12, 2001 4:15 PM To: 'rap@ops.ietf.org' Cc: Sunlin, Richard (c); Rawlins, Diana Subject: COPS-PR DEC NamedClientSI object and framework-pib-04 Notify PRCs All, I need a little clarification on a certain topic: The COPS-PR NamedClientSI object. Here is an excerpt from COPS-PR RFC 3084: The REQ from a policy provisioning client contains a COPS 'Configuration Request' context object and, optionally, any relevant named client specific information from the PEP. Now, here is an excerpt from framework-pib-04: The PIB indicates which capabilities the PEP must report to the PDP by means of the PIB-ACCESS clause as described in [SPPI]. Now, should the "must" in the framework-pib-04 be removed? I am currently interpreting this excerpt to mean that the PDP MUST expect all Notify PRCs in the NamedClientSI objects. However, RFC 3084 states that the NamedClientSI is optional and that a REQ may include 0 or more of these objects. Another question: Should a PDP send a DEC Null if no NamedClientSI objects are encapsulated in the REQ or should defaults be assumed or is that an implementation choice? Tina Iliff --Boundary_(ID_f5/a2lXw3CHgJbSOrEja7w) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: COPS-PR DEC NamedClientSI object and framework-pib-04 Notify = PRCs

Tina Iliff
MCIWorldCom ENSD
(972)729-1620


      -----Original = Message-----
      From:   Iliff, Tina =
      Sent:   Thursday, April 12, 2001 4:15 PM
      To:     'rap@ops.ietf.org'
      Cc:     Sunlin, Richard (c); Rawlins, Diana
      Subject:       = COPS-PR DEC NamedClientSI object and = framework-pib-04 Notify PRCs

      All,

      I need a little clarification on a = certain topic:  The COPS-PR NamedClientSI object.  Here is an = excerpt from COPS-PR RFC 3084:

      The REQ from a policy = provisioning client contains a COPS
      'Configuration Request' context = object and, optionally, any relevant named client specific information = from the PEP.

      Now, here is an excerpt from = framework-pib-04:
      The PIB indicates which = capabilities the PEP must report to the PDP by means of the PIB-ACCESS = clause as described in [SPPI].

      Now, should the "must" in the framework-pib-04 = be removed?  I am currently interpreting this excerpt to mean that = the PDP MUST expect all Notify PRCs in the NamedClientSI objects.  = However, RFC 3084 states that the NamedClientSI is optional and that a = REQ may include 0 or more of these objects. 

      Another question:  Should a PDP send a DEC = Null if no NamedClientSI objects are encapsulated in the REQ or should = defaults be assumed or is that an implementation choice?

      Tina Iliff

--Boundary_(ID_f5/a2lXw3CHgJbSOrEja7w)-- From owner-rap@ops.ietf.org Fri Apr 20 08:25:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10852 for ; Fri, 20 Apr 2001 08:25:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14qY73-000HSC-00 for rap-data@psg.com; Fri, 20 Apr 2001 03:26:05 -0700 Received: from mcigate1.mci.mei.co.jp ([210.146.208.194]) by psg.com with esmtp (Exim 3.16 #1) id 14qY70-000HS5-00 for rap@ops.ietf.org; Fri, 20 Apr 2001 03:26:02 -0700 Received: from postman.mci.mei.co.jp (postman.mci.mei.co.jp [133.185.181.250]) by mcigate1.mci.mei.co.jp (/) with SMTP id TAA19402 for ; Fri, 20 Apr 2001 19:26:00 +0900 (JST) Received: from nsl.mci.mei.co.jp by postman.mci.mei.co.jp (8.9.1/3.7Wpl2:mcihub1:01041117) id TAA17228; Fri, 20 Apr 2001 19:26:00 +0900 (JST) Received: from mexico (mexico.nsc.mci.mei.co.jp [10.77.195.168]) by nsl.mci.mei.co.jp (8.9.3/8.9.3) with SMTP id TAA12257 for ; Fri, 20 Apr 2001 19:25:58 +0900 (JST) (envelope-from shingu@nsl.mci.mei.co.jp) Message-ID: <00ad01c0c984$22fdd360$a8c34d0a@nsc.mci.mei.co.jp> From: "Hideki Shingu" To: Subject: According to purpose of load sharing using policy server with COPS Date: Fri, 20 Apr 2001 19:24:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Could someone please tell me about load sharing in COPS ? Now assumed that there are some internet domain, and each policy server (PS) manages one domain. For example, PS 1 manages domain 1. PS 2 manages domain 2. .................................. PS N manages domain N. In this condition, if I make a MPLS path or a channel from the edge of domain A to the edge of domain C through domain B (domain A is not next to domain C), it is expected that PSs negotiate each other. Like PS1 negotiates with PS2, PS2 negotiates with PS3. But I have no idea how PSs negotiate using COPS or any other protocols, what kind of COPS messages are used in the negotiation, what kind of COPS objects, what kind of routing data.. If someone knows good documents/articles and any other information in this region, please advise me. thanks. Shingu. From owner-rap@ops.ietf.org Sat Apr 21 04:49:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08791 for ; Sat, 21 Apr 2001 04:49:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14qt1c-000CJT-00 for rap-data@psg.com; Sat, 21 Apr 2001 01:45:52 -0700 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14qt1N-000CIr-00 for rap@ops.ietf.org; Sat, 21 Apr 2001 01:45:46 -0700 Received: from sunjian ([10.105.29.2]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GC4W3H01.W0E for ; Sat, 21 Apr 2001 16:40:29 +0800 Message-ID: <000f01c0ca3f$73b58440$021d690a@huawei.com.cn> From: "sunjian" To: Date: Sat, 21 Apr 2001 16:45:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here is an excerpt from COPS RFC 2748: For every DEC message *containing a configuration context* that is received by a PEP, the PEP MUST generate a corresponding Report State message with the Solicited Message flag set describing its success or failure in applying the configuration decision. An excerpt from COPS-PR RFC 3084: ..... As described below, the PEP MUST respond to each and every DEC with a corresponding solicited RPT. A COPS-PR DEC message MUST be treated as a single "transaction", i.e., either all the decisions in a DEC message succeed or they all fail. If they fail, the PEP will rollback to its previous good state, which is the last successful DEC transaction, if any. This allows the PDP to delete some policies only if other policies can be installed in their place. From owner-rap@ops.ietf.org Sat Apr 21 04:56:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08834 for ; Sat, 21 Apr 2001 04:56:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14qt9E-000CNi-00 for rap-data@psg.com; Sat, 21 Apr 2001 01:53:44 -0700 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14qt99-000CMz-00 for rap@ops.ietf.org; Sat, 21 Apr 2001 01:53:41 -0700 Received: from sunjian ([10.105.29.2]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GC4WGX02.50B for ; Sat, 21 Apr 2001 16:48:33 +0800 Message-ID: <001d01c0ca40$943b3600$021d690a@huawei.com.cn> From: "sunjian" To: Subject: Question about RPT Date: Sat, 21 Apr 2001 16:53:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit =============== The question is: If the PDP received a malformed REQ Msg and reply a DEC as following: ::= Will the PEP reply a RPT Msg for such DEC? If the report reply, then what's the report type should be? Thanks sunjian =============== Here is an excerpt from COPS RFC 2748: For every DEC message *containing a configuration context* that is received by a PEP, the PEP MUST generate a corresponding Report State message with the Solicited Message flag set describing its success or failure in applying the configuration decision. An excerpt from COPS-PR RFC 3084: ..... * As described below, the PEP MUST respond to each and every DEC with a corresponding solicited RPT. A COPS-PR DEC message MUST be treated as a single "transaction", i.e., either all the decisions in a DEC message succeed or they all fail. *If they fail, the PEP will rollback to its previous good state, which is the last successful DEC transaction, if any. This allows the PDP to delete some policies only if other policies can be installed in their place. From owner-rap@ops.ietf.org Sat Apr 21 05:37:43 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08954 for ; Sat, 21 Apr 2001 05:37:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14qtpi-000Ciq-00 for rap-data@psg.com; Sat, 21 Apr 2001 02:37:38 -0700 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14qtpe-000CiN-00 for rap@ops.ietf.org; Sat, 21 Apr 2001 02:37:35 -0700 Received: from sunjian ([10.105.29.2]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GC4YI503.G08 for ; Sat, 21 Apr 2001 17:32:29 +0800 Message-ID: <003101c0ca46$b799b800$021d690a@huawei.com.cn> From: "sunjian" To: Subject: Questions about the solicited flag! Date: Sat, 21 Apr 2001 17:37:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Should the Flags in the Msg CAT, SSC be set? Should the Flags in the KA Msg which PDP reply to PEP be set? In COPS RFC 2748, +---------------+--------------+--------------+--------------+ |Version| Flags | Op Code | Client-type | +---------------+--------------+--------------+--------------+ | Message Length | +---------------+--------------+--------------+--------------+ Flags: 4 bits Defined flag values (all other flags MUST be set to 0): 0x1 Solicited Message Flag Bit This flag is set when the message is solicited by another COPS message. This flag is NOT to be set (value=0) ***unless otherwise specified in section 3***. And there's no any specification about the flags in the above massages. Thanks very much! sunjian From owner-rap@ops.ietf.org Mon Apr 23 09:44:26 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04412 for ; Mon, 23 Apr 2001 09:44:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14rgcK-0007Wv-00 for rap-data@psg.com; Mon, 23 Apr 2001 06:43:04 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14rgcK-0007WI-00 for rap@ops.ietf.org; Mon, 23 Apr 2001 06:43:04 -0700 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GC800HNHZA8JN@firewall.mcit.com> for rap@ops.ietf.org; Mon, 23 Apr 2001 13:39:44 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GC800801Z9STM@pmismtp01.wcomnet.com>; Mon, 23 Apr 2001 13:39:44 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GC800852Z9R8P@pmismtp01.wcomnet.com>; Mon, 23 Apr 2001 13:39:27 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Apr 2001 13:39:26 +0000 Content-return: allowed Date: Mon, 23 Apr 2001 13:39:17 +0000 From: "Iliff, Tina" Subject: RE: Question about RPT To: "'sunjian'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F5787@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_EMkOtVymW0YNdh+U1ZmMBA)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_EMkOtVymW0YNdh+U1ZmMBA) Content-type: text/plain; charset=iso-8859-1 Yes, the PEP will reply with a RPT. The Report Type may be either Success or Fail depending on the PEP's ability to process the message. Tina Iliff -----Original Message----- From: sunjian [mailto:jians@huawei.com] Sent: Saturday, April 21, 2001 3:54 AM To: rap@ops.ietf.org Subject: Question about RPT =============== The question is: If the PDP received a malformed REQ Msg and reply a DEC as following: ::= Will the PEP reply a RPT Msg for such DEC? If the report reply, then what's the report type should be? Thanks sunjian =============== Here is an excerpt from COPS RFC 2748: For every DEC message *containing a configuration context* that is received by a PEP, the PEP MUST generate a corresponding Report State message with the Solicited Message flag set describing its success or failure in applying the configuration decision. An excerpt from COPS-PR RFC 3084: ..... * As described below, the PEP MUST respond to each and every DEC with a corresponding solicited RPT. A COPS-PR DEC message MUST be treated as a single "transaction", i.e., either all the decisions in a DEC message succeed or they all fail. *If they fail, the PEP will rollback to its previous good state, which is the last successful DEC transaction, if any. This allows the PDP to delete some policies only if other policies can be installed in their place. --Boundary_(ID_EMkOtVymW0YNdh+U1ZmMBA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Question about RPT

Yes, the PEP will reply with a = RPT.  The Report Type may be either Success or Fail depending on = the PEP's ability to process the message.

Tina Iliff


    -----Original = Message-----
    From:   sunjian [mailto:jians@huawei.com]=
    Sent:   Saturday, April 21, 2001 3:54 AM
    To:     rap@ops.ietf.org
    Subject:       = Question about RPT

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    The question is:
    If the PDP received a malformed = REQ Msg and reply a DEC as following:
       <Decision = Message> ::=3D <Common Header>
               &= nbsp;           &= nbsp;           &= nbsp;       <Client Handle>
               &= nbsp;           &= nbsp;           &= nbsp;       <Error>

    Will the PEP reply a RPT Msg for = such DEC?
    If the report reply, then = what's the report type should be?

    Thanks
    sunjian
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    Here is an excerpt from COPS RFC = 2748:

       For every DEC = message *containing a configuration context* that is
       received by a PEP, = the PEP MUST generate a corresponding Report State
       message with the = Solicited Message flag set describing its success or
       failure in = applying the configuration decision.

    An excerpt from COPS-PR RFC = 3084:

       ..... * As = described below, the PEP MUST respond to each and every DEC with = a
       corresponding = solicited RPT.

       A COPS-PR DEC = message MUST be treated as a single "transaction",
       i.e., either all = the decisions in a DEC message succeed or they all
       fail.  *If = they fail, the PEP will rollback to its previous good
       state, which is = the last successful DEC transaction, if any.  This
       allows the PDP to = delete some policies only if other policies can be
       installed in their = place.



--Boundary_(ID_EMkOtVymW0YNdh+U1ZmMBA)-- From owner-rap@ops.ietf.org Tue Apr 24 09:42:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07833 for ; Tue, 24 Apr 2001 09:42:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14s32W-0002pY-00 for rap-data@psg.com; Tue, 24 Apr 2001 06:39:36 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14s32V-0002pI-00 for rap@ops.ietf.org; Tue, 24 Apr 2001 06:39:35 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GCA00CG2TV22I@firewall.mcit.com> for rap@ops.ietf.org; Tue, 24 Apr 2001 13:37:51 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GCA00I01TUTTS@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Tue, 24 Apr 2001 13:37:50 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GCA00I34TUMDT@dgismtp02.wcomnet.com> for rap@ops.ietf.org; Tue, 24 Apr 2001 13:37:34 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 13:37:33 +0000 Content-return: allowed Date: Tue, 24 Apr 2001 13:37:30 +0000 From: "Iliff, Tina" Subject: FW: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed To: "'rap@ops.ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E3F5791@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_6A/ZHdBcw+7vFV3VK0VkfQ)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_6A/ZHdBcw+7vFV3VK0VkfQ) Content-type: text/plain; charset=ISO-8859-1 Tina Iliff MCIWorldCom ENSD (972)729-1620 -----Original Message----- From: Iliff, Tina Sent: Tuesday, April 17, 2001 5:43 PM To: 'rap@ops.ietf.org' Subject: framework-pib-04: Pib Incarnations "Activation" and "De-activation" Clarification Needed All, One item in the framework-pib-04 draft seems a little ambiguous to me. Please let me know if I am missing something. Specifically, how should one interpret the below RFC 3084 excerpts regarding Pib Incarnations: Specifically, based on this excerpt which endpoint (PEP or PDP) is responsible for setting a Pib Incarnation to "inactive"; i.e. setting its Active attribute to 'False'? It explicitly states that the PDP is responsible for selecting the Active incarnation. My interpretation is that all policy will be sent and indicated as inactive, then the PDP will send just a frwkPibIncarnation instance to "activate" one incarnation identified by its Id. However, who is responsible for "de-activating" currently installed "activated" policy when a new incarnation is sent by the PDP with the Active attribute set to 'True'? Also, please let me know if I am interpreting words incorrectly. Multiple PIB Instances [COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy. The intent is to allow for the pre-provisioning of policy that can then be made active by a single, short decision from the PDP. A COPS context can be defined as an independent COPS request state for a particular subject category (client-type). With the COPS-PR protocol, each of these states is identified by a unique client handle. The creation and deletion of these PIB instances is controlled by the PDP as described in [COPS-PR]. Although many PIB instances may be configured on a device (the maximum number of these instances being determined by the device itself) only one of them can be active at any given time, the active one being selected by the PDP. To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance the active one and, similarly, to report the active PIB instance to the PDP in a COPS request message. This attribute is in the Incarnation Table described below. Setting the attribute frwkPibIncarnationActive to 'true' in one PIB instance MUST ensure that the attribute is 'false' in all other contexts. frwkPibIncarnationActive OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "If this attribute is set to TRUE, then the PIB instance to which this PRI belongs becomes the active PIB instance. The previous active instance MUST become inactive and the frwkPibIncarnationActive attribute in that PIB instance MUST be set to false." Regards, Tina Iliff --Boundary_(ID_6A/ZHdBcw+7vFV3VK0VkfQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FW: framework-pib-04: Pib Incarnations "Activation" = and "De-activation" Clarification Needed

Tina Iliff
MCIWorldCom ENSD
(972)729-1620


-----Original = Message-----
From:   Iliff, Tina =
Sent:   Tuesday, April 17, 2001 5:43 PM
To:     'rap@ops.ietf.org'
Subject:       = framework-pib-04:  Pib = Incarnations "Activation" and "De-activation" = Clarification Needed

All,

One item in the framework-pib-04 draft = seems a little ambiguous to me.  Please let me know if I am = missing something.  Specifically, how should one interpret the = below RFC 3084 excerpts regarding Pib Incarnations: Specifically, based on this excerpt which endpoint (PEP = or PDP) is responsible for setting a Pib Incarnation to "inactive"; = i.e. setting its Active attribute to 'False'?  It explicitly = states that the PDP is responsible for selecting the Active = incarnation.  My interpretation is that all policy will be sent = and indicated as inactive, then the PDP will send just a = frwkPibIncarnation instance to "activate" one incarnation identified by = its Id.  However, who is responsible for "de-activating" currently = installed "activated" policy when a new incarnation is sent by the PDP = with the Active attribute set to 'True'?

Also, please let me know if I am = interpreting words incorrectly.


Multiple PIB Instances
   
   [COPS-PR] supports = multiple, disjoint, independent instances of the
   PIB to represent = multiple instances of configured policy.  The
   intent is to allow = for the pre-provisioning of policy that can then
   be made active by = a single, short decision from the PDP.
   
   A COPS context can = be defined as an independent COPS request state
   for a particular = subject category (client-type). 
 
   With the COPS-PR = protocol, each of these states is identified by a
   unique client = handle.  The creation and deletion of these PIB
   instances is = controlled by the PDP as described in [COPS-PR].
   
   Although many PIB = instances may be configured on a device (the
   maximum number of = these instances being determined by the device
   itself) only one = of them can be active at any given time, the active
   one being selected = by the PDP.  To facilitate this selection, the
   Framework PIB = supports an attribute to make a PIB instance the
   active one and, = similarly, to report the active PIB instance to the
 
   PDP in a COPS = request message. This attribute is in the Incarnation
   Table described = below.
   
   Setting the = attribute frwkPibIncarnationActive to 'true' in one PIB
   instance MUST = ensure that the attribute is 'false' in all other
   contexts.

frwkPibIncarnationActive = OBJECT-TYPE
       = SYNTAX         TruthValue =
       = STATUS         current
       DESCRIPTION
           = "If this attribute is set to TRUE, then the PIB instance
           to = which this PRI belongs becomes the active PIB instance.
           The = previous active instance MUST become inactive and the
           = frwkPibIncarnationActive attribute in that PIB instance 
           MUST = be set to false."


Regards,
Tina Iliff

--Boundary_(ID_6A/ZHdBcw+7vFV3VK0VkfQ)-- From owner-rap@ops.ietf.org Tue Apr 24 11:54:27 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09694 for ; Tue, 24 Apr 2001 11:54:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14s57x-000424-00 for rap-data@psg.com; Tue, 24 Apr 2001 08:53:21 -0700 Received: from jr130.phasecom.co.il ([199.203.189.130]) by psg.com with esmtp (Exim 3.16 #1) id 14s57w-00041y-00 for rap@ops.ietf.org; Tue, 24 Apr 2001 08:53:20 -0700 Received: from WNTS4EXCH.vyyo.co.il (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 24 Apr 2001 18:54:25 +0200 Received: by WNTS4EXCH.vyyo.co.il with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 18:52:05 +0200 Message-ID: From: Arie Nimkovsky To: rap@ops.ietf.org Subject: Using COPS for VoIP call initiation Date: Tue, 24 Apr 2001 18:52:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="koi8-r" Sender: owner-rap@ops.ietf.org Precedence: bulk Hello, Our system uses a layer-2 (bridge) entity through which VoIP calls flow. This bridge should supply resources relevant to VoIP. A Call Agent which manages the call signaling will inform the bridge about the required resources for each call, and the bridge will reply the Call Agent whether it has the requested resources. If it has not - the call request be dropped by the Call Agent. My question: Is COPS suitable for such message exchange? Who is the client and who is the server in this case? It seems to me that the client/server roles are reversed here - the entity that knows about the call in progress is the Call Agent so it is the candidate for the client (PEP) role, however the actual admission will make the bridge, so from this aspect IT should be the policy enforcing point. Can someone to enlighten me on this? If not COPS - may be there is some other more suitable protocol for the stated purposes? Thanks, Arie Nimkovsky ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error (whether inadvertently addressed to you, or if forwarded to you by a recipient), please contact the sender and delete the material from any computer. This footnote also confirms that this email message has been swept by VYYO's Virus Scan Systems for the presence of computer viruses. ********************************************************************** From owner-rap@ops.ietf.org Tue Apr 24 12:07:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09882 for ; Tue, 24 Apr 2001 12:07:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14s5LK-0004B2-00 for rap-data@psg.com; Tue, 24 Apr 2001 09:07:10 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.16 #1) id 14s5LI-0004Aa-00 for rap@ops.ietf.org; Tue, 24 Apr 2001 09:07:09 -0700 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GCB0009F0N04J@firewall.mcit.com> for rap@ops.ietf.org; Tue, 24 Apr 2001 16:04:12 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GCB005010MV9U@pmismtp01.wcomnet.com>; Tue, 24 Apr 2001 16:04:11 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GCB0041V0MHWY@pmismtp01.wcomnet.com>; Tue, 24 Apr 2001 16:03:53 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 16:03:53 +0000 Content-return: allowed Date: Tue, 24 Apr 2001 16:03:51 +0000 From: "Iliff, Tina" Subject: RE: Using COPS for VoIP call initiation To: "'Arie Nimkovsky'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F5798@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_dRJznx1+F2HdS0jp1WXe+A)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_dRJznx1+F2HdS0jp1WXe+A) Content-type: text/plain; charset=iso-8859-1 Arie, It sounds as though COPS Usage for RSVP may be suitable for the scenario which you have described below. Please reference RFC 2749. Tina Iliff -----Original Message----- From: Arie Nimkovsky [mailto:animkovsky@vyyo.co.il] Sent: Tuesday, April 24, 2001 11:52 AM To: rap@ops.ietf.org Subject: Using COPS for VoIP call initiation Hello, Our system uses a layer-2 (bridge) entity through which VoIP calls flow. This bridge should supply resources relevant to VoIP. A Call Agent which manages the call signaling will inform the bridge about the required resources for each call, and the bridge will reply the Call Agent whether it has the requested resources. If it has not - the call request be dropped by the Call Agent. My question: Is COPS suitable for such message exchange? Who is the client and who is the server in this case? It seems to me that the client/server roles are reversed here - the entity that knows about the call in progress is the Call Agent so it is the candidate for the client (PEP) role, however the actual admission will make the bridge, so from this aspect IT should be the policy enforcing point. Can someone to enlighten me on this? If not COPS - may be there is some other more suitable protocol for the stated purposes? Thanks, Arie Nimkovsky ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error (whether inadvertently addressed to you, or if forwarded to you by a recipient), please contact the sender and delete the material from any computer. This footnote also confirms that this email message has been swept by VYYO's Virus Scan Systems for the presence of computer viruses. ********************************************************************** --Boundary_(ID_dRJznx1+F2HdS0jp1WXe+A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Using COPS for VoIP call initiation

Arie,

It sounds as though COPS Usage for = RSVP may be suitable for the scenario which you have described = below.  Please reference RFC 2749.

Tina Iliff


    -----Original = Message-----
    From:   Arie Nimkovsky = [mailto:animkovsky@vyyo.co.il]<= /FONT>
    Sent:   Tuesday, April 24, 2001 11:52 AM
    To:     rap@ops.ietf.org
    Subject:       = Using COPS for VoIP call = initiation

    Hello,

    Our system uses a layer-2 = (bridge) entity through which VoIP calls flow.
    This bridge should supply = resources relevant to VoIP.
    A Call Agent which manages the = call signaling will inform the bridge about
    the required resources for each = call, and the bridge will reply the Call
    Agent whether it has the = requested resources. If it has not - the call
    request be dropped by the Call = Agent.
    My question:
    Is COPS suitable for such = message exchange?  Who is the client and who is
    the server in this case? It = seems to me that the client/server roles are
    reversed here - the entity that = knows about the call in progress is the Call
    Agent so it is the candidate = for the client (PEP) role, however the actual
    admission will make the bridge, = so from this aspect IT should be the policy
    enforcing point.
    Can someone to enlighten me on = this? If not COPS - may be there is some
    other more suitable protocol = for the stated purposes?

    Thanks,
    Arie Nimkovsky


    *******************************************************************= ***
    The information transmitted is = intended only for the person or entity to
    which it is addressed and may = contain confidential and/or privileged
    material.  Any review, = retransmission, dissemination or other use of, or
    taking of any action in = reliance upon, this information by persons or
    entities other than the = intended recipient is prohibited.   If you received
    this in error (whether = inadvertently addressed to you, or if forwarded to
    you by a recipient), please = contact the sender and delete the material from
    any computer.

    This footnote also confirms that = this email message has been swept by
    VYYO's Virus Scan Systems for = the presence of computer viruses.

    *******************************************************************= ***

--Boundary_(ID_dRJznx1+F2HdS0jp1WXe+A)-- From owner-rap@ops.ietf.org Tue Apr 24 12:13:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09997 for ; Tue, 24 Apr 2001 12:13:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14s5R3-0004Ek-00 for rap-data@psg.com; Tue, 24 Apr 2001 09:13:05 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14s5R2-0004E6-00 for rap@ops.ietf.org; Tue, 24 Apr 2001 09:13:04 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GCB00M760YZR3@firewall.mcit.com> for rap@ops.ietf.org; Tue, 24 Apr 2001 16:11:24 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GCB00I010YD0O@dgismtp02.wcomnet.com>; Tue, 24 Apr 2001 16:11:23 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GCB00GEV0YC1S@dgismtp02.wcomnet.com>; Tue, 24 Apr 2001 16:11:00 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 16:11:00 +0000 Content-return: allowed Date: Tue, 24 Apr 2001 16:10:58 +0000 From: "Iliff, Tina" Subject: RE: Using COPS for VoIP call initiation To: "'Arie Nimkovsky'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F5799@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_/MSjsSHdwO11G37Wpff7zw)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_/MSjsSHdwO11G37Wpff7zw) Content-type: text/plain; charset=ISO-8859-1 Arie, RSVP between the Call Agent and the Bridge and COPS-RSVP between the Bridge and a Remote Policy Decision Point (PDP) may be suitable. However, only RSVP between the Call Agents and the Bridges and from Bridge to Bridge or from Bridge to Router may be suitable if the Bridges have Local Policy Decision Point capability. For RSVP, please reference RFC 2205 and 2210. Tina Iliff -----Original Message----- From: Arie Nimkovsky [mailto:animkovsky@vyyo.co.il] Sent: Tuesday, April 24, 2001 11:52 AM To: rap@ops.ietf.org Subject: Using COPS for VoIP call initiation Hello, Our system uses a layer-2 (bridge) entity through which VoIP calls flow. This bridge should supply resources relevant to VoIP. A Call Agent which manages the call signaling will inform the bridge about the required resources for each call, and the bridge will reply the Call Agent whether it has the requested resources. If it has not - the call request be dropped by the Call Agent. My question: Is COPS suitable for such message exchange? Who is the client and who is the server in this case? It seems to me that the client/server roles are reversed here - the entity that knows about the call in progress is the Call Agent so it is the candidate for the client (PEP) role, however the actual admission will make the bridge, so from this aspect IT should be the policy enforcing point. Can someone to enlighten me on this? If not COPS - may be there is some other more suitable protocol for the stated purposes? Thanks, Arie Nimkovsky ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error (whether inadvertently addressed to you, or if forwarded to you by a recipient), please contact the sender and delete the material from any computer. This footnote also confirms that this email message has been swept by VYYO's Virus Scan Systems for the presence of computer viruses. ********************************************************************** --Boundary_(ID_/MSjsSHdwO11G37Wpff7zw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: Using COPS for VoIP call initiation

Arie,

RSVP between the Call Agent and the = Bridge and COPS-RSVP between the Bridge and a Remote Policy Decision = Point (PDP) may be suitable.  However, only RSVP between the Call = Agents and the Bridges and from Bridge to Bridge or from Bridge to = Router may be suitable if the Bridges have Local Policy Decision Point = capability.  For RSVP, please reference RFC 2205 and = 2210.

Tina Iliff


    -----Original = Message-----
    From:   Arie Nimkovsky = [mailto:animkovsky@vyyo.co.il]<= /FONT>
    Sent:   Tuesday, April 24, 2001 11:52 AM
    To:     rap@ops.ietf.org
    Subject:       = Using COPS for VoIP call = initiation

    Hello,

    Our system uses a layer-2 = (bridge) entity through which VoIP calls flow.
    This bridge should supply = resources relevant to VoIP.
    A Call Agent which manages the = call signaling will inform the bridge about
    the required resources for each = call, and the bridge will reply the Call
    Agent whether it has the = requested resources. If it has not - the call
    request be dropped by the Call = Agent.
    My question:
    Is COPS suitable for such = message exchange?  Who is the client and who is
    the server in this case? It = seems to me that the client/server roles are
    reversed here - the entity that = knows about the call in progress is the Call
    Agent so it is the candidate = for the client (PEP) role, however the actual
    admission will make the bridge, = so from this aspect IT should be the policy
    enforcing point.
    Can someone to enlighten me on = this? If not COPS - may be there is some
    other more suitable protocol = for the stated purposes?

    Thanks,
    Arie Nimkovsky


    *******************************************************************= ***
    The information transmitted is = intended only for the person or entity to
    which it is addressed and may = contain confidential and/or privileged
    material.  Any review, = retransmission, dissemination or other use of, or
    taking of any action in = reliance upon, this information by persons or
    entities other than the = intended recipient is prohibited.   If you received
    this in error (whether = inadvertently addressed to you, or if forwarded to
    you by a recipient), please = contact the sender and delete the material from
    any computer.

    This footnote also confirms that = this email message has been swept by
    VYYO's Virus Scan Systems for = the presence of computer viruses.

    *******************************************************************= ***

--Boundary_(ID_/MSjsSHdwO11G37Wpff7zw)-- From owner-rap@ops.ietf.org Tue Apr 24 12:58:05 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10520 for ; Tue, 24 Apr 2001 12:58:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14s665-0004l6-00 for rap-data@psg.com; Tue, 24 Apr 2001 09:55:29 -0700 Received: from rumor.cps.intel.com ([192.102.198.242]) by psg.com with esmtp (Exim 3.16 #1) id 14s664-0004kU-00 for rap@ops.ietf.org; Tue, 24 Apr 2001 09:55:28 -0700 Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id QAA09502; Tue, 24 Apr 2001 16:54:47 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 24 Apr 2001 16:54:51 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 09:54:49 -0700 Message-ID: From: "Kulkarni, Amol" To: "'Iliff, Tina'" , "'rap@ops.ietf.org'" Subject: RE: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed Date: Tue, 24 Apr 2001 09:53:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCDF.1386D270" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0CCDF.1386D270 Content-Type: text/plain; charset="iso-8859-1" Tina, It is my understanding that whenever a PEP receives a decision from a PDP activating a particular PIB instance, the PEP is responsible for de-activating the previously active PIB instance installed on it. Amol -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Tuesday, April 24, 2001 6:38 AM To: 'rap@ops.ietf.org' Subject: FW: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed Tina Iliff MCIWorldCom ENSD (972)729-1620 BM__MailData-----Original Message----- From: Iliff, Tina Sent: Tuesday, April 17, 2001 5:43 PM To: 'rap@ops.ietf.org' Subject: framework-pib-04: Pib Incarnations "Activation" and "De-activation" Clarification Needed All, One item in the framework-pib-04 draft seems a little ambiguous to me. Please let me know if I am missing something. Specifically, how should one interpret the below RFC 3084 excerpts regarding Pib Incarnations: Specifically, based on this excerpt which endpoint (PEP or PDP) is responsible for setting a Pib Incarnation to "inactive"; i.e. setting its Active attribute to 'False'? It explicitly states that the PDP is responsible for selecting the Active incarnation. My interpretation is that all policy will be sent and indicated as inactive, then the PDP will send just a frwkPibIncarnation instance to "activate" one incarnation identified by its Id. However, who is responsible for "de-activating" currently installed "activated" policy when a new incarnation is sent by the PDP with the Active attribute set to 'True'? Also, please let me know if I am interpreting words incorrectly. Multiple PIB Instances [COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy. The intent is to allow for the pre-provisioning of policy that can then be made active by a single, short decision from the PDP. A COPS context can be defined as an independent COPS request state for a particular subject category (client-type). With the COPS-PR protocol, each of these states is identified by a unique client handle. The creation and deletion of these PIB instances is controlled by the PDP as described in [COPS-PR]. Although many PIB instances may be configured on a device (the maximum number of these instances being determined by the device itself) only one of them can be active at any given time, the active one being selected by the PDP. To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance the active one and, similarly, to report the active PIB instance to the PDP in a COPS request message. This attribute is in the Incarnation Table described below. Setting the attribute frwkPibIncarnationActive to 'true' in one PIB instance MUST ensure that the attribute is 'false' in all other contexts. frwkPibIncarnationActive OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "If this attribute is set to TRUE, then the PIB instance to which this PRI belongs becomes the active PIB instance. The previous active instance MUST become inactive and the frwkPibIncarnationActive attribute in that PIB instance MUST be set to false." Regards, Tina Iliff ------_=_NextPart_001_01C0CCDF.1386D270 Content-Type: text/html; charset="iso-8859-1" FW: framework-pib-04: Pib Incarnations "Activation" and "De-activation" Clarification Needed
Tina,
 
It is my understanding that whenever a PEP receives a decision from a PDP activating a particular PIB instance, the PEP is responsible for de-activating the previously active PIB instance installed on it.
 
Amol
-----Original Message-----
From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
Sent: Tuesday, April 24, 2001 6:38 AM
To: 'rap@ops.ietf.org'
Subject: FW: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed


Tina Iliff
MCIWorldCom ENSD
(972)729-1620


-----Original Message-----
From:   Iliff, Tina
Sent:   Tuesday, April 17, 2001 5:43 PM
To:     'rap@ops.ietf.org'
Subject:        framework-pib-04:  Pib Incarnations "Activation" and "De-activation" Clarification Needed

All,

One item in the framework-pib-04 draft seems a little ambiguous to me.  Please let me know if I am missing something.  Specifically, how should one interpret the below RFC 3084 excerpts regarding Pib Incarnations: Specifically, based on this excerpt which endpoint (PEP or PDP) is responsible for setting a Pib Incarnation to "inactive"; i.e. setting its Active attribute to 'False'?  It explicitly states that the PDP is responsible for selecting the Active incarnation.  My interpretation is that all policy will be sent and indicated as inactive, then the PDP will send just a frwkPibIncarnation instance to "activate" one incarnation identified by its Id.  However, who is responsible for "de-activating" currently installed "activated" policy when a new incarnation is sent by the PDP with the Active attribute set to 'True'?

Also, please let me know if I am interpreting words incorrectly.


Multiple PIB Instances
   
   [COPS-PR] supports multiple, disjoint, independent instances of the
   PIB to represent multiple instances of configured policy.  The
   intent is to allow for the pre-provisioning of policy that can then
   be made active by a single, short decision from the PDP.
   
   A COPS context can be defined as an independent COPS request state
   for a particular subject category (client-type). 
 
   With the COPS-PR protocol, each of these states is identified by a
   unique client handle.  The creation and deletion of these PIB
   instances is controlled by the PDP as described in [COPS-PR].
   
   Although many PIB instances may be configured on a device (the
   maximum number of these instances being determined by the device
   itself) only one of them can be active at any given time, the active
   one being selected by the PDP.  To facilitate this selection, the
   Framework PIB supports an attribute to make a PIB instance the
   active one and, similarly, to report the active PIB instance to the
 
   PDP in a COPS request message. This attribute is in the Incarnation
   Table described below.
   
   Setting the attribute frwkPibIncarnationActive to 'true' in one PIB
   instance MUST ensure that the attribute is 'false' in all other
   contexts.

frwkPibIncarnationActive OBJECT-TYPE
       SYNTAX         TruthValue
       STATUS         current
       DESCRIPTION
           "If this attribute is set to TRUE, then the PIB instance
           to which this PRI belongs becomes the active PIB instance.
           The previous active instance MUST become inactive and the
           frwkPibIncarnationActive attribute in that PIB instance 
           MUST be set to false."


Regards,
Tina Iliff

------_=_NextPart_001_01C0CCDF.1386D270-- From owner-rap@ops.ietf.org Tue Apr 24 14:11:54 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11766 for ; Tue, 24 Apr 2001 14:11:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14s7GV-0005ZK-00 for rap-data@psg.com; Tue, 24 Apr 2001 11:10:19 -0700 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.16 #1) id 14s7GQ-0005YA-00 for rap@ops.ietf.org; Tue, 24 Apr 2001 11:10:14 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id SAA22233; Tue, 24 Apr 2001 18:09:43 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 24 Apr 2001 18:09:43 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 11:09:41 -0700 Message-ID: <75F7304BB41CD411B06600A0C98414FC015B71E4@ORSMSX54> From: "Sahita, Ravi" To: "Kulkarni, Amol" , "'rap@ops.ietf.org'" , "'Iliff, Tina'" Subject: RE: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed Date: Tue, 24 Apr 2001 11:09:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCE9.B66CE510" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0CCE9.B66CE510 Content-Type: text/plain; charset="iso-8859-1" Right. The PDP always selects the active incarnation. If the PEP receives a decision from the PDP, in which another PIB instance (from the one currently active) is active, the PEP is responsible to make sure ALL the other PIB instances installed for that client-type have a status of not-active. Ravi -----Original Message----- From: Kulkarni, Amol [mailto:amol.kulkarni@intel.com] Sent: Tuesday, April 24, 2001 9:53 AM To: 'Iliff, Tina'; 'rap@ops.ietf.org' Subject: RE: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed Tina, It is my understanding that whenever a PEP receives a decision from a PDP activating a particular PIB instance, the PEP is responsible for de-activating the previously active PIB instance installed on it. Amol -----Original Message----- From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Tuesday, April 24, 2001 6:38 AM To: 'rap@ops.ietf.org' Subject: FW: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed Tina Iliff MCIWorldCom ENSD (972)729-1620 BM__MailData-----Original Message----- From: Iliff, Tina Sent: Tuesday, April 17, 2001 5:43 PM To: 'rap@ops.ietf.org' Subject: framework-pib-04: Pib Incarnations "Activation" and "De-activation" Clarification Needed All, One item in the framework-pib-04 draft seems a little ambiguous to me. Please let me know if I am missing something. Specifically, how should one interpret the below RFC 3084 excerpts regarding Pib Incarnations: Specifically, based on this excerpt which endpoint (PEP or PDP) is responsible for setting a Pib Incarnation to "inactive"; i.e. setting its Active attribute to 'False'? It explicitly states that the PDP is responsible for selecting the Active incarnation. My interpretation is that all policy will be sent and indicated as inactive, then the PDP will send just a frwkPibIncarnation instance to "activate" one incarnation identified by its Id. However, who is responsible for "de-activating" currently installed "activated" policy when a new incarnation is sent by the PDP with the Active attribute set to 'True'? Also, please let me know if I am interpreting words incorrectly. Multiple PIB Instances [COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy. The intent is to allow for the pre-provisioning of policy that can then be made active by a single, short decision from the PDP. A COPS context can be defined as an independent COPS request state for a particular subject category (client-type). With the COPS-PR protocol, each of these states is identified by a unique client handle. The creation and deletion of these PIB instances is controlled by the PDP as described in [COPS-PR]. Although many PIB instances may be configured on a device (the maximum number of these instances being determined by the device itself) only one of them can be active at any given time, the active one being selected by the PDP. To facilitate this selection, the Framework PIB supports an attribute to make a PIB instance the active one and, similarly, to report the active PIB instance to the PDP in a COPS request message. This attribute is in the Incarnation Table described below. Setting the attribute frwkPibIncarnationActive to 'true' in one PIB instance MUST ensure that the attribute is 'false' in all other contexts. frwkPibIncarnationActive OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "If this attribute is set to TRUE, then the PIB instance to which this PRI belongs becomes the active PIB instance. The previous active instance MUST become inactive and the frwkPibIncarnationActive attribute in that PIB instance MUST be set to false." Regards, Tina Iliff ------_=_NextPart_001_01C0CCE9.B66CE510 Content-Type: text/html; charset="iso-8859-1" FW: framework-pib-04: Pib Incarnations "Activation" and "De-activation" Clarification Needed
Right. The PDP always selects the active incarnation. If the PEP receives a decision from the PDP,
in which another PIB instance (from the one currently active) is active, the PEP is responsible to make sure ALL the other PIB
instances installed for that client-type have a status of not-active.
Ravi
 
-----Original Message-----
From: Kulkarni, Amol [mailto:amol.kulkarni@intel.com]
Sent: Tuesday, April 24, 2001 9:53 AM
To: 'Iliff, Tina'; 'rap@ops.ietf.org'
Subject: RE: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed

Tina,
 
It is my understanding that whenever a PEP receives a decision from a PDP activating a particular PIB instance, the PEP is responsible for de-activating the previously active PIB instance installed on it.
 
Amol
-----Original Message-----
From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
Sent: Tuesday, April 24, 2001 6:38 AM
To: 'rap@ops.ietf.org'
Subject: FW: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed


Tina Iliff
MCIWorldCom ENSD
(972)729-1620


-----Original Message-----
From:   Iliff, Tina
Sent:   Tuesday, April 17, 2001 5:43 PM
To:     'rap@ops.ietf.org'
Subject:        framework-pib-04:  Pib Incarnations "Activation" and "De-activation" Clarification Needed

All,

One item in the framework-pib-04 draft seems a little ambiguous to me.  Please let me know if I am missing something.  Specifically, how should one interpret the below RFC 3084 excerpts regarding Pib Incarnations: Specifically, based on this excerpt which endpoint (PEP or PDP) is responsible for setting a Pib Incarnation to "inactive"; i.e. setting its Active attribute to 'False'?  It explicitly states that the PDP is responsible for selecting the Active incarnation.  My interpretation is that all policy will be sent and indicated as inactive, then the PDP will send just a frwkPibIncarnation instance to "activate" one incarnation identified by its Id.  However, who is responsible for "de-activating" currently installed "activated" policy when a new incarnation is sent by the PDP with the Active attribute set to 'True'?

Also, please let me know if I am interpreting words incorrectly.


Multiple PIB Instances
   
   [COPS-PR] supports multiple, disjoint, independent instances of the
   PIB to represent multiple instances of configured policy.  The
   intent is to allow for the pre-provisioning of policy that can then
   be made active by a single, short decision from the PDP.
   
   A COPS context can be defined as an independent COPS request state
   for a particular subject category (client-type). 
 
   With the COPS-PR protocol, each of these states is identified by a
   unique client handle.  The creation and deletion of these PIB
   instances is controlled by the PDP as described in [COPS-PR].
   
   Although many PIB instances may be configured on a device (the
   maximum number of these instances being determined by the device
   itself) only one of them can be active at any given time, the active
   one being selected by the PDP.  To facilitate this selection, the
   Framework PIB supports an attribute to make a PIB instance the
   active one and, similarly, to report the active PIB instance to the
 
   PDP in a COPS request message. This attribute is in the Incarnation
   Table described below.
   
   Setting the attribute frwkPibIncarnationActive to 'true' in one PIB
   instance MUST ensure that the attribute is 'false' in all other
   contexts.

frwkPibIncarnationActive OBJECT-TYPE
       SYNTAX         TruthValue
       STATUS         current
       DESCRIPTION
           "If this attribute is set to TRUE, then the PIB instance
           to which this PRI belongs becomes the active PIB instance.
           The previous active instance MUST become inactive and the
           frwkPibIncarnationActive attribute in that PIB instance 
           MUST be set to false."


Regards,
Tina Iliff

------_=_NextPart_001_01C0CCE9.B66CE510-- From owner-rap@ops.ietf.org Wed Apr 25 08:55:54 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13574 for ; Wed, 25 Apr 2001 08:55:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sOon-0001uN-00 for rap-data@psg.com; Wed, 25 Apr 2001 05:54:53 -0700 Received: from mail4.registeredsite.com ([64.224.9.13]) by psg.com with esmtp (Exim 3.16 #1) id 14sOon-0001uH-00 for rap@ops.ietf.org; Wed, 25 Apr 2001 05:54:53 -0700 Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217]) by mail4.registeredsite.com (8.11.1/8.11.1) with ESMTP id f3PCspI18421 for ; Wed, 25 Apr 2001 08:54:51 -0400 Date: Wed, 25 Apr 2001 08:54:49 -0400 Message-Id: <200104250854.AA1432944972@mail.cominsights.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "vijains" Reply-To: To: Subject: Question on Request message COPS-PR X-Mailer: Sender: owner-rap@ops.ietf.org Precedence: bulk Hello, This question is regarding the Request Message in COPS-PR. Q.When does the question of sending clientSI array arrise ?Because if the PEP is sending incarnation, configuration data to the PDP, only one ClientSI object can incapsulate the whole thing. An extract from the COPS-PR RFC 3084- "The format of the information encapsulated in one or more of the COPS Named ClientSI objects is described in section 5." ::= *() [] Please clarify, Vijai From owner-rap@ops.ietf.org Wed Apr 25 09:53:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15834 for ; Wed, 25 Apr 2001 09:53:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sPhB-0002gW-00 for rap-data@psg.com; Wed, 25 Apr 2001 06:51:05 -0700 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14sPhA-0002g4-00 for rap@ops.ietf.org; Wed, 25 Apr 2001 06:51:04 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GCC000IOP1LCW@firewall.mcit.com> for rap@ops.ietf.org; Wed, 25 Apr 2001 13:48:57 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GCC00701P1B8W@dgismtp02.wcomnet.com>; Wed, 25 Apr 2001 13:48:57 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GCC0062RP16H5@dgismtp02.wcomnet.com>; Wed, 25 Apr 2001 13:48:42 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 13:48:41 +0000 Content-return: allowed Date: Wed, 25 Apr 2001 13:48:38 +0000 From: "Iliff, Tina" Subject: RE: Question on Request message COPS-PR To: "'vijains@mail.cominsights.com'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F57A0@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_vDc1664DtI9sYBiyXVHt8g)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_vDc1664DtI9sYBiyXVHt8g) Content-type: text/plain; charset=ISO-8859-1 Vijai, I am not sure if I understand your question but here is some more information. COPS-PR does not requires 0 or more NamedClientSI objects within the REQ message. Therefore, the PEP may not send any NamedClientSI objects. Another possibility is that the PEP may encapsulate each framework PIB Notify PRC instance in it's own NamedClientSI object. The true answer depends on one's PEP implementation. Does this help at all? Tina Iliff -----Original Message----- From: vijains [mailto:vijains@mail.cominsights.com] Sent: Wednesday, April 25, 2001 7:55 AM To: rap@ops.ietf.org Subject: Question on Request message COPS-PR Hello, This question is regarding the Request Message in COPS-PR. Q.When does the question of sending clientSI array arrise ?Because if the PEP is sending incarnation, configuration data to the PDP, only one ClientSI object can incapsulate the whole thing. An extract from the COPS-PR RFC 3084- "The format of the information encapsulated in one or more of the COPS Named ClientSI objects is described in section 5." ::= *() [] Please clarify, Vijai --Boundary_(ID_vDc1664DtI9sYBiyXVHt8g) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: Question on Request message COPS-PR

Vijai,

I am not sure if I understand your = question but here is some more information.  COPS-PR does not = requires 0 or more NamedClientSI objects within the REQ message.  = Therefore, the PEP may not send any NamedClientSI objects.  = Another possibility is that the PEP may encapsulate each framework PIB = Notify PRC instance in it's own NamedClientSI object.  The true = answer depends on one's PEP implementation.  Does this help at = all?

Tina Iliff


      -----Original = Message-----
      From:   vijains [mailto:vijains@mail.cominsi= ghts.com]
      Sent:   Wednesday, April 25, 2001 7:55 AM
      To:     rap@ops.ietf.org
      Subject:       = Question on Request message = COPS-PR

      Hello,

       This question is regarding the = Request Message in COPS-PR.

      Q.When does the question of sending = clientSI array arrise ?Because if the PEP is sending incarnation, = configuration data to the PDP, only one ClientSI object can incapsulate = the whole thing.

       An extract from the COPS-PR RFC = 3084-

       "The format of the = information encapsulated in one or more of the COPS
       Named ClientSI objects is = described in section 5."

       <Request> ::=3D <Common = Header>
               &nb= sp;           &nb= sp;         <Client = Handle>
               &nb= sp;           &nb= sp;         <Context =3D = config request>
               &nb= sp;           &nb= sp;         *(<Named = ClientSI>)
               &nb= sp;           &nb= sp;         = [<Integrity>]


       Please clarify,
       Vijai

--Boundary_(ID_vDc1664DtI9sYBiyXVHt8g)-- From owner-rap@ops.ietf.org Wed Apr 25 16:45:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00661 for ; Wed, 25 Apr 2001 16:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sW8u-000A5w-00 for rap-data@psg.com; Wed, 25 Apr 2001 13:44:08 -0700 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.16 #1) id 14sW8t-000A3c-00 for rap@ops.ietf.org; Wed, 25 Apr 2001 13:44:07 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id UAA20645 for ; Wed, 25 Apr 2001 20:43:36 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 25 Apr 2001 20:43:36 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 13:43:35 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18A80@orsmsx35.jf.intel.com> From: "Gross, Gerhard" To: "'rap@ops.ietf.org'" Subject: FW: Using COPS for VoIP call initiation Date: Wed, 25 Apr 2001 13:43:33 -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 Arie, We have implemented a COPS extension for SIP in house which does something very similar to what you describe. The SIP proxy (call agent) is the PEP and a policy server is contacted for a policy based admission decision. The policy server may base its decision on a variety of criteria. Standards work is ongoing: http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt http://www.ietf.org/internet-drafts/draft-gross-sipaq-01.txt Gery > -----Original Message----- > From: Arie Nimkovsky [mailto:animkovsky@vyyo.co.il] > Sent: Tuesday, April 24, 2001 9:52 AM > To: rap@ops.ietf.org > Subject: Using COPS for VoIP call initiation > > > Hello, > > Our system uses a layer-2 (bridge) entity through which VoIP > calls flow. > This bridge should supply resources relevant to VoIP. > A Call Agent which manages the call signaling will inform the > bridge about > the required resources for each call, and the bridge will > reply the Call > Agent whether it has the requested resources. If it has not - the call > request be dropped by the Call Agent. > My question: > Is COPS suitable for such message exchange? Who is the > client and who is > the server in this case? It seems to me that the > client/server roles are > reversed here - the entity that knows about the call in > progress is the Call > Agent so it is the candidate for the client (PEP) role, > however the actual > admission will make the bridge, so from this aspect IT should > be the policy > enforcing point. > Can someone to enlighten me on this? If not COPS - may be > there is some > other more suitable protocol for the stated purposes? > > Thanks, > Arie Nimkovsky > > > ********************************************************************** > The information transmitted is intended only for the person > or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other > use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. > If you received > this in error (whether inadvertently addressed to you, or if > forwarded to > you by a recipient), please contact the sender and delete the > material from > any computer. > > This footnote also confirms that this email message has been swept by > VYYO's Virus Scan Systems for the presence of computer viruses. > > ********************************************************************* From owner-rap@ops.ietf.org Mon Apr 30 11:42:44 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15916 for ; Mon, 30 Apr 2001 11:42:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uFmh-000BOR-00 for rap-data@psg.com; Mon, 30 Apr 2001 08:40:23 -0700 Received: from birch.ee.vt.edu ([128.173.88.34]) by psg.com with esmtp (Exim 3.16 #1) id 14uFmg-000BOA-00 for rap@ops.ietf.org; Mon, 30 Apr 2001 08:40:22 -0700 Received: from yew.ee.vt.edu (yew.ee.vt.edu [128.173.88.43]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id LAA11233 for ; Mon, 30 Apr 2001 11:40:20 -0400 (EDT) Received: from localhost (kphanse@localhost) by yew.ee.vt.edu (8.9.3+Sun/8.9.1) with SMTP id LAA08810 for ; Mon, 30 Apr 2001 11:40:19 -0400 (EDT) Date: Mon, 30 Apr 2001 11:40:19 -0400 (EDT) From: Kaustubh Phanse To: rap@ops.ietf.org Subject: PDP interactions in multiple domains Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi! Had a couple of queries in how things would work in multiple policy domains, and whether any standardization was done or being done for the same? Consider the following scenario: We have three network domains, each belonging to a different organization, and each domain has its own PDP to dictate policy decisions. Now say these organizations decide to connect these domains to form a virtual private network (VPN), and would like to have "homogeneous" or "non-conflicting" policies to manage the entire VPN. In such case, how do the PDPs interact to achieve this? Do the PEPs in a domain need to be made aware of (or need to connect) to PDP(s) from other domain(s)?...etc. Section 4.3 in RFC 2753 mentions the following: "The PDP may consult other PDPs, but the discussion of inter-PDP communication and coordination is outside the scope of this document". So, I was not sure, if any other standards documents deals with this, or whether its more of an implementation issue?? Any comments/pointers in this matter are greatly appreaciated. Thank you regards Kaustubh ----------------------------------------------------------------------------- Kaustubh S. Phanse kphanse@ee.vt.edu PhD student http://www.ee.vt.edu/~kphanse Alexandria Research Institute Electrical & Computer Engineering Department Virginia Polytechnic Institute & State University ----------------------------------------------------------------------------- From owner-rap@ops.ietf.org Mon Apr 30 12:06:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16923 for ; Mon, 30 Apr 2001 12:06:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uGAY-000CLO-00 for rap-data@psg.com; Mon, 30 Apr 2001 09:05:02 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.16 #1) id 14uGAX-000CKd-00 for rap@ops.ietf.org; Mon, 30 Apr 2001 09:05:01 -0700 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GCM006614N0KJ@firewall.mcit.com> for rap@ops.ietf.org; Mon, 30 Apr 2001 16:04:13 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GCM003014MWWV@pmismtp01.wcomnet.com>; Mon, 30 Apr 2001 16:04:12 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GCM002864MKIK@pmismtp01.wcomnet.com>; Mon, 30 Apr 2001 16:03:56 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Apr 2001 16:03:56 +0000 Content-return: allowed Date: Mon, 30 Apr 2001 16:03:50 +0000 From: "Iliff, Tina" Subject: RE: PDP interactions in multiple domains To: "'Kaustubh Phanse'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F57BD@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_23jo10XKDVq3WiADbKqNMw)" Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_23jo10XKDVq3WiADbKqNMw) Content-type: text/plain; charset=iso-8859-1 Kaustubh, I believe that it is an implementation issue. In other words, functions such as DSCP values negotiation between two domains as well as determining what one PDP had installed on a PEP prior to the PEP connecting to another PDP after connection loss, etc are currently implementation issues. Tina Iliff -----Original Message----- From: Kaustubh Phanse [mailto:kphanse@ee.vt.edu] Sent: Monday, April 30, 2001 10:40 AM To: rap@ops.ietf.org Subject: PDP interactions in multiple domains Hi! Had a couple of queries in how things would work in multiple policy domains, and whether any standardization was done or being done for the same? Consider the following scenario: We have three network domains, each belonging to a different organization, and each domain has its own PDP to dictate policy decisions. Now say these organizations decide to connect these domains to form a virtual private network (VPN), and would like to have "homogeneous" or "non-conflicting" policies to manage the entire VPN. In such case, how do the PDPs interact to achieve this? Do the PEPs in a domain need to be made aware of (or need to connect) to PDP(s) from other domain(s)?...etc. Section 4.3 in RFC 2753 mentions the following: "The PDP may consult other PDPs, but the discussion of inter-PDP communication and coordination is outside the scope of this document". So, I was not sure, if any other standards documents deals with this, or whether its more of an implementation issue?? Any comments/pointers in this matter are greatly appreaciated. Thank you regards Kaustubh ---------------------------------------------------------------------------- - Kaustubh S. Phanse kphanse@ee.vt.edu PhD student http://www.ee.vt.edu/~kphanse Alexandria Research Institute Electrical & Computer Engineering Department Virginia Polytechnic Institute & State University ---------------------------------------------------------------------------- - --Boundary_(ID_23jo10XKDVq3WiADbKqNMw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: PDP interactions in multiple domains

Kaustubh,

I believe that it is an implementation = issue.  In other words, functions such as DSCP values negotiation = between two domains as well as determining what one PDP had installed = on a PEP prior to the PEP connecting to another PDP after connection = loss, etc are currently implementation issues.

Tina Iliff



      -----Original = Message-----
      From:   Kaustubh Phanse = [mailto:kphanse@ee.vt.edu]
      Sent:   Monday, April 30, 2001 10:40 AM
      To:     rap@ops.ietf.org
      Subject:       = PDP interactions in multiple = domains


      Hi!

              Had a couple of queries in how things would work in = multiple
      policy domains, and whether any = standardization was done or being done for
      the same?

      Consider the following = scenario:
      We have three network domains, each = belonging to a different organization,
      and each domain has its own PDP to = dictate policy decisions. Now say these
      organizations decide to connect these = domains to form a virtual private
      network (VPN), and would like to have = "homogeneous" or "non-conflicting"
      policies to manage the entire VPN. In = such case, how do the PDPs interact
      to achieve this? Do the PEPs in a = domain need to be made aware of (or need
      to connect) to PDP(s) from other = domain(s)?...etc.

      Section 4.3 in RFC 2753 mentions the = following:
      "The PDP may consult other PDPs, = but the discussion of inter-PDP
      communication and coordination is = outside the scope of this document".

      So, I was not sure, if any other = standards documents deals with this, or
      whether its more of an implementation = issue??

      Any comments/pointers in this matter = are greatly appreaciated.

      Thank you
      regards
      Kaustubh
      ---------------------------------------------------------= --------------------
       Kaustubh S. = Phanse     =         =         =         =           kphanse@ee.vt.edu
       PhD student    =         =         =         =        http://www.ee.vt.edu/~kphanse
       Alexandria Research = Institute
       Electrical & Computer = Engineering Department   =         =             =   
       Virginia Polytechnic Institute = & State University
      ---------------------------------------------------------= --------------------

--Boundary_(ID_23jo10XKDVq3WiADbKqNMw)--