Subject: RE: [midcom] Winnowing down the list

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 12 Nov 2002 11:18:33 +0100

Martin,
I believe that it is clearly stated in the protocol evaluation document that
several PDPs can access to the same resource by using an underlying resource
management function assisted with local policies. I think we have closed on
this
one before the previous IETF meeting.
Cedric

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]]
Sent: 12 November 2002 11:03
To: Hamer, Louis-Nicolas [CAR:AN22:EXCH]
Cc: [email-masked]
Subject: Re: [midcom] Winnowing down the list

Louis-Nicolas Hamer wrote:

> Melinda, all,
[....]

> 
> The only reason invoked against COPS was the directionality requirement. 
> Kwok explained in great lengths how this was not a big deal - it can be 
> fixed quite easily. So I object to your proposal to remove COPS.

Hmm, there is another reason against COPS:
The COPS PEP is not able to receive configuration data from multiple PDP 
for the *same* resource, e.g. the middlebox can not receive policy rule 
configuration requests from different agents for the same packet filter 
at the same time.

Martin

> 
> As I have indicated before, I think COPS, SNMP and MEGACO are very good 
> fits for MIDCOM.
> I would suggest that the best way forward would be to see what the WG 
> decides on the approach to take to
> "pinpoint" the best protocol to use - I believe you have
> that point on the agenda for the Atlanta meeting, right?
> 
> l-n
> 
> 
>  > -----Original Message-----
>  > From: Melinda Shore [mailto:[email-masked]]
>  > Sent: Friday, November 08, 2002 4:51 PM
>  > To: [email-masked]
>  > Subject: [midcom] Winnowing down the list
>  >
>  >
>  > I'd like to continue to try to narrow the list of midcom
>  > candidates.  From the discussion so far it looks like a lot
>  > of people are dubious about COPS, so here's the question:
>  >
>  > Is there any objection to removing COPS from the list of
>  > candidate midcom protocols?  If you object, please give a reason.
>  >
>  > Melinda
>  > _______________________________________________
>  > midcom mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/midcom
>  >
> 

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 12 Nov 2002 11:24:59 +0100

Cedric Aoun wrote:

> management function assisted with local policies. I think we have closed 
> on this

...with the words (see meeting minutes):
There is a glaring mismatch between MIDCOM framework and COPS
model.

Martin

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 12 Nov 2002 15:11:40 +0100

Cedric,

> one before the previous IETF meeting.

I agree, we have closed this issue as far as the text in the evaluation
document is concerend. All protocols have several advantages and some
problems. However, the evaluation document does neither weight the problems,
nor does it give a recommendation concerning protocol selection.

Therefore, we now have to enter the next stage. We have to weight the
advantages and disadvantages of the protocols in order to get closer to
a recommendation ot better: a protocol selection. And as far as I
understand Martin, he is not aiming at changing any line in the
evaluation, but at getting closer to a recommendation.

One step in this direction is looking again at the disadvantages of the
candidate protocols, which are described in the evaluation document.
And then we have to find out for each of them, whether it is just a minor
disadvantage or a serious problem.

In the case you are discussing with Martin, I see at first glance technical
problem that can be solved, but I am not happy with using COPS-PR while
violating its specification in RFC 3084.

RFC 3084 says:

    "There may be one or more PIBs for given area of policy and
     different areas of policy may have different sets of PIBs."
     (Section 1)

So let's assume we have a Midcom PIB in the Midcom area.

    "Second, as it [COPS] has a single connection between the
     policy client and server per area of policy control identified
     by a COPS Client-Type, it guarantees only one server updates
     a particular policy configuration at any given time.  Such a
     policy configuration is effectively locked, even from local
     console configuration, while the PEP is connected to a PDP
     via COPS." (Section 1.1)

Conclusion: only a single Midcom agent would be allowed to request
or release middlebox resources. I know that technically we could just
ignore this and it works, but I do not feel comfortable when doing so.

Support for doing so is given by

    "In order to support a model that includes multiple PDPs
     controlling non-overlapping areas of policy on a single PEP, the
     client-type specified by the PEP to the PDP is unique for the area
     of policy being managed.  A single client-type for a given area of
     policy (e.g., QoS) will be used for all PIBs that exist in that
     area.  The client should treat all the COPS-PR client-types it
     supports as non-overlapping and independent namespaces where
     instances MUST NOT be shared." (Section 1)

So maybe we can map agent identfiers to client types and use a lot of
existing COPS functonality. But still it leaves the impression of a
hack rather than of a solution.

    Juergen