Subject: Re: [midcom] Midcom proposal: please read

From: Juergen Quittek <[email-masked]>
Date: Tue, 03 Dec 2002 18:12:43 +0100

Jerome,

-- Jerome Moisand wrote on 27 November 2002 10:16 -0500:

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

That's correct.

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

Agreed.

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

I would like to shortcut it, but only with good arguments.

> (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
>
>
>> 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.
>
> => and my answers
>
>>
>>     Juergen
>>
>> > 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
>>
>> Yes, CLI is really most widely implemented as configuration protocol.
>> 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 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
>>
>> 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.
>
> => 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).

Maybe there is an argument, that SNMP is the protocol which is most likely
to be implemented on a managed box anyway. And in the future, I expect SNMPv1
and SNMPv2c to be replaced step by step by SNMPv3.

>
>> > 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
>>
>> 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.
>
> => 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?

I'll do so.

>> > 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.
>>
>> 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'?
>
> => 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!

agreed.

> => 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.
>
>> >
>> > 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.
>>
>> On this point, I fully agree with you!
>
> => hey, we did agree on a couple of things, great!  ;-)
>
>> >
>> > Tx
>> > Jerome Moisand (Juniper Networks)
>> >
>> > > Melinda Shore wrote:
>> > >
>> > > > 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
>> > > >
>> >
>> >
>> > _______________________________________________
>> > midcom mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/midcom
>> >
>> --
>
> _______________________________________________
> 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: Rajeev K R <[email-masked]>
Date: Wed, 04 Dec 2002 10:52:30 +0800

Hi,

The example flow shown in draft-ietf-midcom-semantics-00.txt requires a PRR.
But PRR is optional for a middle box.
So how can the MIDCOM agent realise this call if the middlebox does not
support PRR ?

(In case this is already answered in the list please forward me some of the
relevant mails...)

Regards,
Rajeev

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 04 Dec 2002 10:42:35 +0100

Rajeev,

Thank you for reading the draft and commenting it!

Yes, you are right, the example would not work without PRR.
It was intentionally chosen to (also) show the need for PRR.

However, there are many scenarios that work well with just PER.
Therefore, we labeled PRR as optional. But the reasons for this
decision are not very strong.

Do you suggest to move PRR from optional to mandatory?

    Juergen

---

From: Rajeev K R <[email-masked]>
Date: Wed, 04 Dec 2002 20:37:35 +0800

Hi Juergen,
Thanks for the response.

In the example, the requirement from the midcom agent is that it should get
an outside-IP address of the
NAT to include in the SDP in the INVITE to be sent to user B.

So it issues a PRR and get an outside-IP address reserved from NAT. As per
the draft, this is required because if the call agent does not know the IP
address of user B. Infect it knows the call signalling address of user B to
which it should send the INVITE, but there is no guarantee that this IP
address will be used for media transmission.

So if PRR is not supported by the middle box this can be solved like this:
The midcom agent first issue a PER with whatever IP address of user B as it
knows and create a rule. use the outside-IP in the PER response to modify
the SDP and send it out. When the 200 OK comes from user B , if the IP
address in SDP is same as the call signalling address there is no issue. But
if it is different, the call agent has to delete the existing rule and
create a new rule with this IP address(remember-there is no way to modify a
rule).
But this flow does not seems very logical. You are creating a rule with some
IP address which you are not very sure of, and later modifying the whole
thing. This scenario is possible in case of media servers etc. which may use
multiple network interfaces.
I am looking forward for any other solution that you guys might have.

So if we do not have PRR support, it makes the call flow possibly more
complex.
For me it looks like PRR is a very logical way of starting up :- where you
do not know much about the external entity and you start with reserving one
outside-IP address in NAT and then creating rules around that.

> Do you suggest to move PRR from optional to mandatory?
Yes. I do.

From my experience, the more "optional" items you have, the more complex the
protocol becomes :)

Regards,
Rajeev

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 04 Dec 2002 15:59:19 +0100

Rajeev,

You propose to move the PRR transaction from optional to mandatory.
I am not very determined whether to do this or not.
Maybe there are more opinions out there?
Let's discuss it as semantics issue #8:

Summary: The PRR transaction reserves addresses at a middlebox without
creating a pinhole or address binding. This is required for some typical
SIP signaling scenarios. However, there are many scenarios where PRR
is not necessary. Currently is is labeled in the semnatics document as
an optional transaction. Therefore, some middleboxes may not work well
in some SIP signalling scenarios.

Proposal by Rajeev: move the PRR transaction from optional to mandatory

Advantage: All SIP scenarios studied so far would work.
Disadvantage: Implementation might be hard (or impossible?) for some NATs.

    Juergen

Rajeev, please see some more commens in line below.

> address will be used for media transmission.

In general, this is not the address of B's terminal,
but the address of the SIP server where B is registered.

> I am looking forward for any other solution that you guys might have.

We don't have another one. The solution is offering PRR.

---

From: Rajeev K R <[email-masked]>
Date: Thu, 05 Dec 2002 09:23:16 +0800

Hi Juergen,
Please see my comments inline,
Rajeev

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: "Rajeev K R" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 04, 2002 10:59 PM
Subject: Semantics issue #8: PRR mandatory? (was: Re: [midcom] PRR support)

> in some SIP signalling scenarios.
The example taken was SIP. But the same situation would be there for H323,
MGCP or Megaco.
So let us take it as an issue not specific to SIP, but related to all VOIP
protocols.

> >> > The example flow shown in draft-ietf-midcom-semantics-00.txt requires
a
> > PRR.
> >> > (In case this is already answered in the list please forward me some
of
> > the

---

From: Miao Fuyou <[email-masked]>
Date: Thu, 05 Dec 2002 11:29:01 +0800

If we consider SNMP overall（regardless v1, v2 or v3）as a protocol, I
believe nobody would disagree that it's a widely deployed one. Actually
v3 shares so many features with v1 or v2, which are definitely widely
deployed. What is more, the philosophy and primary architecture behide
them are leave unchanged when it evolved.  So, I think we should
evaluate the effect of v1/v2 popularity to v3 intead of v3 alone. 

BTW, I am new to the WG, the sentences above don't imply any preference.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Wednesday, December 04, 2002 1:13 AM
To: Jerome Moisand; [email-masked]
Subject: Re: [midcom] Midcom proposal: please read

Jerome,

-- Jerome Moisand wrote on 27 November 2002 10:16 -0500:

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

That's correct.

> I was not making a case for choosing this protocol or against it, I do

> see multiple Pros & Cons for SNMPv3 (and the others).

Agreed.

> (see below a few more details for clarification, but not really adding

> much to my points).
>> 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?
>> > 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

> people will balk at this terminology!  ;-) => Yes, we're in complete 
> agreement here.
>
>> > 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
>>
>> 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.
>
> => 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).

Maybe there is an argument, that SNMP is the protocol which is most
likely to be implemented on a managed box anyway. And in the future, I
expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3.

>> 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.
>
> 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?

I'll do so.

>> > 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.
>> 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,
>> it was not really designed. The situation would certainly be 
>> different, if COPS was already implemented widely for policy-based 
>> configuration of
> devices.
> => 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!

agreed.

> => 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.
>> > (to me) to hold much water. I believe the "midcom" group needs to 
>> > find a better rationale (and process) for making such decision.
>>
>> > > > 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]
>> > [email-masked] https://www1.ietf.org/mailman/listinfo/midcom
>> >
>> --
>

---

From: "Christopher A. Martin" <[email-masked]>
Date: Wed, 04 Dec 2002 21:46:29 -0600

Hi all, sorry I'm late on the thread as usual, 

I agree with SNMP v3 as a potential protocol for this purpose but am not
sure that I agree with the comments about popularity of the earlier
versions ot v3 mentioned below, since I am concerned with security of
midcom implemtation wrt the choice between v1/v2 and v3. I don’t think
that the first two are valid for reasons of message integrity of the
protocol signaling.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miao Fuyou
Sent: Wednesday, December 04, 2002 9:29 PM
To: [email-masked]
Subject: RE: [midcom] Midcom proposal: please read

-----Original Message-----

Jerome,

That's correct.

Agreed.

I'll do so.

agreed.

---

From: Miao Fuyou <[email-masked]>
Date: Thu, 05 Dec 2002 11:53:29 +0800

Hi, Chris

I don't mean v1 or v2 can adapt midcom context, but please consider: if
a developer is familiar with v1/v2 he/she can understand SNMPv3 easily,
which will help midcom implementation.

Regards
Miao 

-----Original Message-----
From: Christopher A. Martin [mailto:[email-masked]] 
Sent: Thursday, December 05, 2002 11:46 AM
To: 'Miao Fuyou'; [email-masked]
Subject: RE: [midcom] Midcom proposal: please read

Chris

-----Original Message-----

Jerome,

That's correct.

Agreed.

I'll do so.

agreed.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Wed, 04 Dec 2002 22:22:02 -0600

Ahh, totally agree, wont feel foreign at all to many individuals.

:^)

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miao Fuyou
Sent: Wednesday, December 04, 2002 9:53 PM
To: 'Christopher A. Martin'
Cc: [email-masked]
Subject: RE: [midcom] Midcom proposal: please read

Hi, Chris

Regards
Miao 

-----Original Message-----
From: Christopher A. Martin [mailto:[email-masked]] 
Sent: Thursday, December 05, 2002 11:46 AM
To: 'Miao Fuyou'; [email-masked]
Subject: RE: [midcom] Midcom proposal: please read

Chris

-----Original Message-----

Jerome,

That's correct.

Agreed.

I'll do so.

agreed.