Subject: RE: Outsourcing and Provisioning common model

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 31 Jan 2002 17:07:53 -0500

The notion of converging the Outsourcing and Provisioning model was first
raised in the context of the Access Bind PIB. The reason was that Access
Bind is in effect designed to configure/provision the criteria for
signalling (outsourcing) a request to the PDP. It was explicitly designed to
allow a PEP to be provisioned with both the criteria for initiating an
outsource request (in our case the detection of a new session) and to also
provision the PEP with the pieces of information that should be passed with
the request (port, headers, etc.)

The reason why normalization of Outsourcing and Provisioning was raised was
because we realized that this PIB could also be used to provision a PEP to
detect and notify the PDP when RSVP PATH/RESV messages were detected. What
was even more interesting was that by using this PIB for RSVP outsouring, we
could provide far more than just a YES or NO answer to the PEP. We could in
fact use the DS and Framework PIBs to explicitly specify the QoS semantics
for the reservation. Since very few switches in fact support WFQ on a per
reservation basis, this allows the PDP to use the PIB Capabilities semantics
to assign the optimal router components to meet the reservation
requirements.

As such the arguement for normalization is to take the best of both COPS and
COPS-PR, and merge them together. The question is how much should this
normalization depend explicitly on the Access Bind PIB? At the meeting, I
believe Shai argued that he would like to see some of these concepts moved
from the Access Bind PIB to the Framework PIB.

regards,

-Walter

> -----Original Message-----
> From: Nguyen Thi Mai Trang [mailto:[email-masked]]
> Sent: Thursday, January 31, 2002 10:38 AM
> To: [email-masked]
> Subject: Re: Outsourcing and Provisioning common model
> 
> 
> 
> Hi everybody,
> 
> I'm also interested in this presentation at 52th IETF. This 
> mode take advantage
> of both the dynamicity of Outsourcing mode and the 
> flexibility of using PIB of
> Configuration mode. I had a question about "What type of 
> ClientSI (Signaled
> ClientSI or Named ClientSI) we can use in the unifed mode?" 
> that was supposed to
> discussed in the mailling list.
> 
> I would like to know in COPS-UMTS, which type of ClientSI 
> object is intended to
> be used?
> 
> In my opinon, and also in COPS-SLS, I used Signaled ClientSI  
> because the
> objective of the information in the clientSI object is 
> signalling in despite of
> their form of PIB. I preferes the terminology "Using PIB in 
> Outsourcing mode" to
> "Using COPS-PR in Outsourcing mode" because, for me, COPS-PR 
> is already the
> provisioning mode. "Using Provisioning mode in Outsourcing 
> mode" sounds not
> logic :-)
> 
> What do you think about it?
> Thanks,
> Mai Trang
> 
> Yacine El Mghazli wrote:
> 
> > Hi everybody,
> >
> > At the last IETF meeting, Shai Herzog launched a discussion 
> about a COPS
> > common model merging both outsourcing and provisioning 
> modes. The fact was
> > that some recent drafts use COPS-PR to OUTSOURCE 
> information towards the PDP
> > (umts, access-bind, sls...) and the goal was to identify 
> where the 2 modes
> > meets and to agree on a common model.
> >
> > This discussion was supposed to take place on the mailing 
> list, but...
> > doesnt come !
> >
> > Speaking as a co-author of the cops-sls draft, I'm 
> wondering about this
> > common model and, after all, about the future of such practises.
> >
> > thanks,
> > yacine
> >
> > -- Yacine El Mghazli
> > 
> ----------------------------------------------------------------------
> >   Alcatel R&I
> >   Next Generation Router & Cross-Connect - NGRX
> >   Marcoussis, France
> >   Tel  +33 1 6963 4187
> >   Fax  +33 1 6963 1169
> >   [email-masked]
> > 
> ----------------------------------------------------------------------
> >
> > ----- Original Message -----
> > From: "Da Silva, Pedro" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Thursday, January 31, 2002 12:08 PM
> > Subject: RE: A question about SPPI
> >
> > > Man, Ravi,
> > >
> > > The uniqueness clause also states that "The specified set 
> of attributes
> > > provide a necessary and sufficient set of values by which 
> to identify an
> > > instance of this PRC".
> > > As such does an optional attribute constitute a necessary one for
> > UNIQUENESS
> > > clauses?
> > > Also, considering the case where a UNIQUENESS clause's 
> set is composed of
> > > optional attributes only, does that constitute a 
> sufficient set by which
> > to
> > > identify an instance of the PRC?
> > >
> > > cheers,
> > > Pedro
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Sahita, Ravi [mailto:[email-masked]]
> > > Sent: Wednesday, January 30, 2002 11:50 PM
> > > To: [email-masked]'; [email-masked]
> > > Subject: RE: A question about SPPI
> > >
> > >
> > > Man Li,
> > >
> > > The UNIQUENESS clause itself is optional. The SPPI does
> > > not put any constraints on which attributes can be specified
> > > in this clause other than -
> > > 1.  The attribute named in the PIB-INDEX clause may not be
> > >     present in the UNIQUENESS clause.
> > > 2. An attribute may not appear more than once in a UNIQUENESS
> > >    clause.
> > >
> > > So, yes, the UNIQUNESS clause can contain optional attributes
> > > as long as it follows the rules above.
> > >
> > > Hope that helps,
> > > Ravi
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Monday, January 28, 2002 11:08 AM
> > > To: [email-masked]
> > > Subject: A question about SPPI
> > >
> > >
> > > In a PIB table, some attributes can be optional. Should 
> the UNIQUENESS
> > > clause exclude optional attributes? In other words, can a 
> UNIQUENESS
> > clause
> > > contain any optional attributes?
> > >
> > > Man Li
> > >
> 
> --
> ----------------------------------------------------
> Nguyen Thi Mai Trang
> Ecole Nationale Superieure des Telecommunications
> Dept. INFRES - Bur. C234-4
> 46 Rue Barrault - 75013 Paris
> Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19
> email : [email-masked]
> 
> 
>

---

From: "Moisand, Jerome" <[email-masked]>
Date: Thu, 31 Jan 2002 18:10:26 -0500

Yes, agreed, Shai speech sounded right to the point to me, and it would be
real nice to hear the COPS experts discuss this "common" model.

1. I'm afraid that COPS-PR will always stay controversial if it's viewed as
a pure provisioning play. (please don't flame me! have mercy! ;-)

2. The outsourcing model tends to generate quite a load of traffic by having
to manage each handle (and related policy objects) fully independently.
Would be nice to be able to *reference* (and often share) pre-defined
profiles.

3. It always made me uncomfortable to see outsourcing discussions being
centered on RSVP sessions. There are many other types of sessions where
outsourced dynamic decision (at session establishment, during its "life", or
at deletion) could be very useful. Think RSVP but also PPP, EAP, DHCP, IGMP,
IPSec associations, all sorts of tunnels, LSPs, etc. Also possibly routing
protocols adjacencies, etc. Anything which is signaling-oriented. As well as
various objects configured in a more static way in nature (e.g. SNMP or the
dreaded CLI ;-), but still requiring dynamic policing in a
transaction-oriented way. 

Now when you think to a merged model, where various things intended to be
shared can be provisioned in advance or 'just in time' via COPS-PR via a
"coarse-grain" handle, and referenced by decisions made on more dynamic and
fine-grain objects (handles in the outsourced model), then the whole picture
is becoming WAY more attractive. At least for me...

I suspect that technically speaking, we are actually close to such 'merged'
behavior, notably with the new framework PIB, simply it seems to never be
discussed or illustrated in tutorial/educational/examples material. 

So putting all these thoughts together, yes, would be nice to see this
thread of discussion more active... and possibly captured in the updated
policy management framework/umbrella document that the WG recently
initiated.

Jerome

-----Original Message-----
From: Yacine El Mghazli [mailto:[email-masked]]
Sent: Thursday, January 31, 2002 9:38 AM
To: [email-masked]
Subject: Outsourcing and Provisioning common model

Hi everybody,

At the last IETF meeting, Shai Herzog launched a discussion about a COPS
common model merging both outsourcing and provisioning modes. The fact was
that some recent drafts use COPS-PR to OUTSOURCE information towards the PDP
(umts, access-bind, sls...) and the goal was to identify where the 2 modes
meets and to agree on a common model.

This discussion was supposed to take place on the mailing list, but...
doesnt come !

Speaking as a co-author of the cops-sls draft, I'm wondering about this
common model and, after all, about the future of such practises.

thanks,
yacine

-- Yacine El Mghazli

----- Original Message -----
From: "Da Silva, Pedro" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 31, 2002 12:08 PM
Subject: RE: A question about SPPI

> Man, Ravi,
>
> The uniqueness clause also states that "The specified set of attributes
> provide a necessary and sufficient set of values by which to identify an
> instance of this PRC".
UNIQUENESS
> clauses?
> Also, considering the case where a UNIQUENESS clause's set is composed of
> optional attributes only, does that constitute a sufficient set by which
to
> In a PIB table, some attributes can be optional. Should the UNIQUENESS
> clause exclude optional attributes? In other words, can a UNIQUENESS
clause

---

From: <[email-masked]>
Date: Thu, 31 Jan 2002 20:36:43 -0500

Hi,

If I understand it correctly, 3GPP would like to use COPS-PR for the GO interface and they have a tight schedule for their next release. If we keep on changing the COPS protocols, is it possible that people who are friendly with COPS will pick up an alternative solution (SNMP or even Radius) simply for stability reasons. By the time we come up with a perfect COPS solution, many have already stood behind other protocols. This applies not only to folks in 3GPP but also to those who are interested in using COPS for policy management. Timing may be everything for gaining market recognition. Without market share, what is a perfect solution good for? 

Man