Subject: Re: [midcom] topology considerations again [was: Reminder: wg last call ]

From: [email-masked]
Date: Wed, 17 Sep 2003 13:02:08 -0400

One of the issues that Jürgen and Pyda are disagreeing about centers on
whether a midcom agent can, or should, have knowledge of interfaces of the
middlebox it interacts with and if the semantics of the midcom protocol
should take that into account.

Paraphrasing Pyda:   "NAT is configured on a per-interface basis. As such,
the Midcom/NAT transactions would be specified on a per-interface basis."

Ultimately this comes to topology. This was a hot issue in this working
group 2 years ago. We had at least 3 different topology considerations
documents discussing the issue. At the time, I think Melinda rather
skillfully steered the group away from this weighty topic and onto the more
basic task of specifying requirements for midcom.

It seems to me that we have come full circle and I sense that if we do get
into topology again, we won't be too long before we again start discussing
'realms', 'in-and-out', global namespaces etc. At the same time, it is last
call for the document so we should speak up now.

Some questions come to mind:

Do the semantics that we have specified unnecessarily constrain the
configuration of midcom agents and middleboxes to simple topology's?

Do we have indeed to deal with midcom agents with multiple interfaces?

Are topology considerations out-of-scope for the working group? If so, are
we really just leaving it up to implementers to deal with the topology
issue in proprietary ways?

Can the semantics be adapted without too much complexity to deal with
topology? Do the need to be?

 Is our extensibility story good enough that an implementer could attach
'interface' information to transactions?

My own review of the semantics document is that it is good enough for the
kinds of simple uses of midcom I have in mind. I think though that it is
reasonable to ask these questions now.

We can take a look at some of the older messages (for example this one by
Andrew Molitor) to get a sense of past thinking on the topology issue

http://www.ietf.org/mail-archive/working-groups/midcom/current/msg01152.html

--
Koranteng Ofosu-Amaah
Portal Solutions - Lotus Software - IBM

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Sep 2003 13:35:46 -0400

> issue in proprietary ways?

Yes, topology considerations are out-of-scope and we're really
leaving it up to implementers to deal with them.  The question of
specifying interfaces is inextricable from the question of
pushing routing information out to the agent, which would be a
terrible mistake.  As I said earlier my preference would be
that the request from the agent would not contain an interface
identifier and that the middlebox would select one based on its
own understanding of the network topology.

However, the question of overlapping address spaces is a serious
one, and I do think that it would be useful to allow an optional
interface identifier includable in the request for dealing with
this in a proprietary way.  I expect it would be abused, but I
don't think that's sufficient cause to refuse to include an
otherwise useful protocol element.

Thanks very much for pointing out the earlier discussions.

Melinda

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 17 Sep 2003 22:38:50 +0200

> otherwise useful protocol element.

I do not see a problem with adding an optional parameter to the
PRR and PER transactions.  The parameter being optional implies
that in general the middlebox should be able to handle requests
not containing this parameter.

It looks like we need two optional interface parameters, 
one for each 'side' of the middlebox?
 
    Juergen

--

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 18 Sep 2003 11:00:00 +0200

Hi Koranteng,

thanks for poiting to the old dicussions on topology issues.

As Juergen has mentioned in his email, I also agree with adding an optional 
interface parameter to the PRR and PER transactions, although I think that 
a common agent implementation won't uses that.

My view is that the goal of MIDCOM is actually to relief the middlebox of 
the ALG processing burden and not to load some new burden to the ALG, as 
the toplogoy issue would certainly do. I would imaging the smile of a SIP 
proxy implementor that has to deal with NAT interfaces and mapping tables 
in addition to controlling SIP transactions.

Thanks
Martin

--On Wednesday, September 17, 2003 13:02:08 -0400 
[email-masked] wrote:

|
|
|
|
| One of the issues that Jürgen and Pyda are disagreeing about centers on
| whether a midcom agent can, or should, have knowledge of interfaces of the
| middlebox it interacts with and if the semantics of the midcom protocol
| should take that into account.
|
| Paraphrasing Pyda:   "NAT is configured on a per-interface basis. As such,
| the Midcom/NAT transactions would be specified on a per-interface basis."
|
| Ultimately this comes to topology. This was a hot issue in this working
| group 2 years ago. We had at least 3 different topology considerations
| documents discussing the issue. At the time, I think Melinda rather
| skillfully steered the group away from this weighty topic and onto the
| more basic task of specifying requirements for midcom.
|
| It seems to me that we have come full circle and I sense that if we do get
| into topology again, we won't be too long before we again start discussing
| 'realms', 'in-and-out', global namespaces etc. At the same time, it is
| last call for the document so we should speak up now.
|
| Some questions come to mind:
|
| Do the semantics that we have specified unnecessarily constrain the
| configuration of midcom agents and middleboxes to simple topology's?
|
| Do we have indeed to deal with midcom agents with multiple interfaces?
|
| Are topology considerations out-of-scope for the working group? If so, are
| we really just leaving it up to implementers to deal with the topology
| issue in proprietary ways?
|
| Can the semantics be adapted without too much complexity to deal with
| topology? Do the need to be?
|
|  Is our extensibility story good enough that an implementer could attach
| 'interface' information to transactions?
|
| My own review of the semantics document is that it is good enough for the
| kinds of simple uses of midcom I have in mind. I think though that it is
| reasonable to ask these questions now.
|
| We can take a look at some of the older messages (for example this one by
| Andrew Molitor) to get a sense of past thinking on the topology issue
|
| http://www.ietf.org/mail-archive/working-groups/midcom/current/msg01152.h
| tml
|
|
|
| --
| Koranteng Ofosu-Amaah
| Portal Solutions - Lotus Software - IBM
|
|
| _______________________________________________
| midcom mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/midcom

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 18 Sep 2003 19:40:04 -0700 (PDT)

That sounds good. Thanks.

cheers,
suresh

> > Thanks very much for pointing out the earlier discussions.

=====