Subject: [midcom] Midcom proposal: please read

From: Melinda Shore <[email-masked]>
Date: Mon, 25 Nov 2002 08:48:20 -0500

There was a proposal made during the midcom session at the
IETF meeting to shortcut the protocol selection process and
just go with SNMPv3 as the midcom protocol.  Consistent with
IETF process, this is a decision to be made on the mailing
list.  I'd like to come to a decision within the next week
or so (Thursday is Thanksgiving in the US and many people
may be away this week).

Thanks,

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

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 26 Nov 2002 12:10:13 +0100

I have a question regarding SNMP and setting multiple values at the same 
time. Perhaps this is a very basic question, but I see some problems here.

For MIDCOM it is required to configure all data of the policy rule at 
the same time and to get the data really configured (all or nothing 
principle). In SNMP you can set one value and check wether this has been 
set properly or not. What about SNMP if you have to set 5-tuples at the 
same time. Is there any mechanism in the SNMP protocol that allow this 
or do we have to create our own mechanism?

A word ahead: I would appreciate detailed answers and not just plain 
answers like "It works because it is defined", since I'm not aware about 
all geat features in SNMPv3.

Martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Nov 2002 10:56:22 -0500

It is a reasonable question.

THe semantics of SNMP are defined such that if a single PDU has multiple 
SETs, then they MUST be done atomically.  That is, either all of them are 
done or none of them are done.
Thus, semantically, this is a match for what MIDCOM requires.

It is worth noting that the realities of protocols make this a less than 
perfect match.  The SNMP requirement applies to the requests in a single 
message.  Currently, that is a single UDP datagram.  Since we do not want 
to put in a dependence on the forthcoming SNMP over TCP, this does limit 
the scope of atomicity.  I believe the limitation is acceptable, but it is 
as far as I know a real limit.  (There are those who would argue that IP 
Fragmentation would allow a larger UDP datagram.  Bad answer.)

Yours,
Joel M. Halpern

PS: THis particular aspect of SNMP semantics is part of SNMPv1 as well as v3.

At 12:10 PM 11/26/2002 +0100, Martin Stiemerling wrote:
>For MIDCOM it is required to configure all data of the policy rule at the 
>same time and to get the data really configured (all or nothing 
>same time. Is there any mechanism in the SNMP protocol that allow this or 
>do we have to create our own mechanism?
>

---

From: "Jerome Moisand" <[email-masked]>
Date: Tue, 26 Nov 2002 12:01:20 -0500

Hello,

I'm new to this list, so apologies in advance if I might repeat what other
people already stated.

If I remember well, the main point made during the midcom session about
shorcutting the protocol selection process was that SNMP is way more widely
implemented than other protocol candidates.

I am not sure to see the value of this point.

First, SNMP is definitely widely implemented, but essentially for monitoring
purposes (alarms & stats). It seems a big stretch to say that SNMP is widely
implemented for provisioning & for authorization, where protocols like CLI
and Radius are by far the most widely deployed. Also SNMPv1 and to a lesser
extent SNMPv2 are widely used, but it also seems a big stretch to say that
SNMPv3 is widely implemented. Just look at the largest router manufacturer
general strategy in this respect...

Second, the fact that a protocol is widely implemented doesn't make it
suitable for all purposes. Both Diameter and COPS have been designed to
allow better processing for transaction-oriented policy decisions (which is
exactly what midcom is about, I believe). Both protocols were intended to
address such situations that SNMP and Radius were not good at. If it were
not the case, why did IETF spend so much time working on these two new
protocols? Also note that the mere fact that these protocols have been
recently defined makes it obvious that they are not yet widely implemented.
So? Should we never use next-gen protocols on this basis? I don't believe
so.

Bottomline: I wouldn't understand why such a "decision shortcut" would be
used on the basis of this "wide implementation" argument, which doesn't seem
(to me) to hold much water. I believe the "midcom" group needs to find a
better rationale (and process) for making such decision.

Tx
Jerome Moisand (Juniper Networks)

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 27 Nov 2002 15:31:08 +0100

Hi Jerome,

I am also not sure whether or not SNMP would be a good choice for
MIDCOM. But your arguments confused me. Do you want to say "everything
else would be better? Or do you see a good candidate, you would
prefer?

Please see some more comments inline.

    Juergen

> implemented for provisioning & for authorization, where protocols like CLI

Yes, CLI is really most widely implemented as configuration protocol.
But this is not at all a protocol (maybe it is 1000 protocols :-).

> suitable for all purposes. Both Diameter and COPS have been designed to

First you compare SNMPv3 to CLI and say its much less widely used. This
is completely right, but not useful at all. Now you compare it to COPS
and Diameter. Compared to Diameter (and probably also COPS), SNMPv3 is
indeed widely used.

> address such situations that SNMP and Radius were not good at. If it were

Please exlain! How is COPS addressing the "mutliple clients configuring
a single server while addressing the same (kind of) resources)" situation? 
I would say: not at all.
  
> So? Should we never use next-gen protocols on this basis? I don't believe

I cannot follow your argument. We are using a lot of very recent protocols,
but do we have to choose them always, just because the are new? If COPS-PR 
is not even widely used in it's original domain, policy-based configuration,
yet, then why should I already consider using it for other purposes for which
it was not really designed. The situation would certainly be different, if
COPS was already implemented widely for policy-based configuration of devices.
But since it is not (and I personally see it coming soon, why should I choose
it? Because it is 'next-gen'?

> better rationale (and process) for making such decision.

On this point, I fully agree with you!

--

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 27 Nov 2002 15:56:24 +0100

Joel,

> Thus, semantically, this is a match for what MIDCOM requires.

I think for most MIDCOM transactions it would not be a problem to
fit all parameters into a single PDU. But the SNMP spec saying
that the order in which the sets are executed is not deterministic,
makes it hard to 
  1. create a row for a new policy,
  2. fill all objects of the row, and
  3. set the row to be active (or enabled)
with a single PDU. Rather, I think three PDUs are required for
this. However, you can still provide atomicity, by having not impact
at all on the middlebox behavior after step 1 and 2 and then enabling
the policy int the atomic step 3. You can even add to the semantics
of step 3 that the entire row will be deleted, if step 3 fails.

    Juergen

---

From: "Jerome Moisand" <[email-masked]>
Date: Wed, 27 Nov 2002 10:16:59 -0500

Juergen,

I was just saying that choosing SNMPv3 because it's "widely deployed" isn't
a convincing argument at all.

I was not making a case for choosing this protocol or against it, I do see
multiple Pros & Cons for SNMPv3 (and the others).

I just wanted to express the opinion that we shouldn't shortcut the
decision-making process.

(see below a few more details for clarification, but not really adding much
to my points).

Tx
Jerome

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: "Jerome Moisand" <[email-masked]>
Cc: <[email-masked]>; "Melinda Shore" <[email-masked]>
Sent: Wednesday, November 27, 2002 9:31 AM
Subject: Re: [midcom] Midcom proposal: please read

> Please see some more comments inline.

=> and my answers

> But this is not at all a protocol (maybe it is 1000 protocols :-).

=> I facetiously referred to CLI as a protocol, knowing well that many
people will balk at this terminology!  ;-)
=> Yes, we're in complete agreement here.

> and Diameter. Compared to Diameter (and probably also COPS), SNMPv3 is

=> everything is relative, but all in all, none of the proposed candidates
(SNMPv3 for provisioning, Diameter, COPS) is widely used yet, far from it.
By either Network Elements, or OSS systems. Or let's say, not to a point
where it should become a significant factor in our decision-making. These
three protocols clearly remain to be proven on the field. This is only my
perception, of course (probably tainted by the fact that I know well Service
Providers environments, but less enterprise networking).

> a single server while addressing the same (kind of) resources)" situation?

=> this is another thread of discussion. I did hear Melinda express
reservations on this point, but this deserves a separate e-mail thread. I'll
come back on this, as well as the transaction aspect of midcom (where I
think SNMPv3 has a big issue).

=> maybe somebody would be kind enough to copy & paste some previous e-mail
thread on this topic, and forward it to me? Just to not making you guys
repeat yourselves?

> it? Because it is 'next-gen'?

=> funny the way you took the direct negation of my statement! You're saying
we should NOT *always* use recent protocols just because they are recent. I
was just saying that we should NOT *always* use old protocols (or new
flavors of an old protocol) just because they are 'old' (hence 'proven') and
have been widely used for a completly different application (e.g.
monitoring). Well, both statements are fair, I believe!

=> maybe I don't fully understand yet what midcom is about, but I do see
this as a dynamic policy management problem with transactional properties.
So it only seems natural to look at policy management protocols. Which the
group rightfully did, without jumping to hasty conclusions. All this sounds
fair to me. But suddenly shortcutting such process based on a very debatable
point, that, I have to disagree with.

> On this point, I fully agree with you!

=> hey, we did agree on a couple of things, great!  ;-)

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2002 10:56:20 -0500

> I just wanted to express the opinion that we shouldn't shortcut the

To the contrary - the scores among the various protocols as
presented in the evaluation document are very close, and if
there are intangibles that were not possible to quantify
that allow us to short-cut a protracted and likely
unproductive discussion, by all means we should do so.
Obviously if there is non-trivial dissent we won't forge on
ahead with SNMPv3 without more fully considering the other
candidates.  We aren't there yet.

Melinda

---

From: "Cullen Jennings" <[email-masked]>
Date: Wed, 27 Nov 2002 08:40:00 -0800

Agreeing with Jerome ...

SNMP may be right but I don't see it as dead obvious right now so I think we
should look carefully at the options - and we need to look at how much we
will need to change the option to make it work. TCP is widely implemented
and we could send things with lots of <> brackets over it. Question is, how
much effort will it be to get any of these options implemented, doing the
right thing, and widely deployed. From the discussion so far, it is not
clear to me that any proposal is a clear winner over the others.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jerome Moisand
> Sent: Tuesday, November 26, 2002 9:01 AM
> To: Melinda Shore
> Cc: [email-masked]

---

From: "Jerome Moisand" <[email-masked]>
Date: Wed, 27 Nov 2002 16:31:02 -0500

Yes, I don't disagree with you, Melinda.

My sentence was to be read in a context where I was expressing the opinion
that the so-called "wide" implementation of SNMP (more precisely SNMPv3 for
provisioning) didn't appear as such "intangible", far from it.

Was another "intangible" identified and agreed upon?

Jerome