Subject: RE: [midcom] policy & duration

From: John LaCour <[email-masked]>
Date: Thu, 9 Aug 2001 09:16:50 -0700

I dont think the problem is different.

Even if you only have two interfaces you might have
packets that go in and out the same interface.

What is important is that the Middlebox know which
path to apply the MIDCOM request to.

It can either be told explicitly by the agent, it can
try to figure it out on its own - explicit policy
such as the middlebox MIDCOM server being tied to
a specific path or implicitly by something such
as routing.

If we decide we want the agent to tell it explicitly
then we need to decide what kind of data model
for Path will work for all cases of middleboxes.

I support the Middlebox figuring it out on its own
with one small caveat.  An one-token identifier
be included in the protocol to identify which logical
middlebox path this request applies to.  That way
we don't need to have multiple MIDCOM dialogues for
multiple logical middleboxes and Paths.

-John

> -----Original Message-----
> From: Mark Pietras [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 7:05 AM
> To: [email-masked]
> Subject: RE: [midcom] policy & duration
> 
> 
> Can someone clarify for me what we're talking about here:
> 
> To me, there are two types of multiple-interfaces:
> 
> 1) I'll call it the ABC-type, where packets arriving on 
> interface A may exit on interface B or interface C (and all 
> the other combinations or a subset thereof)
> 
> 2) I'll call it the NxAB-type, where packets arriving on the 
> interface A of a pair exit on the corresponding interface B 
> of the pair (and visa-versa).
> 
> ABC is a much harder problem to solve than NxAB.  Which 
> multiple-interface type are we discussing?
> 
> Mark.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Paul Sijben
> Sent: Thursday, August 09, 2001 8:45 AM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: Re: [midcom] policy & duration
> 
> 
> Melinda,
> 
> the issue is clearer when you also address the point that is 
> outside the
> scope of MIDCOM, namely discovery of middleboxes. 
> 
> If you do not address that problem you have *no* idea where 
> the flows are
> going to end up and you can only push a generic policy to *all*
> middleboxes in your network rather than send clear commands 
> to *one* box.
> Obviously, this does not scale. 
> 
> So assuming sufficuently large networks that make midcom deployment
> interesting (rather than stuffing all application intelligence in the
> firewall), you need to know where the flow is going to hit a 
> middlebox and
> (assuming middleboxes with more than 2 interfaces) you need 
> to know where
> the flow needs to go to.
> 
> This makes the midcom agent party to the network topology 
> information as
> far as it needs to know. 
> 
> Now, I am OK that we leave the aspect of getting that kind of 
> information
> to the agent out of the discussion but we can hardly ignore the larger
> architectural impact.  
> 
> Paul
> 
> Melinda Shore wrote:
> > 
> > > From: "Paul Sijben" <[email-masked]>
> > 
> > > If a midcom agent takes charge of a packet flow through a 
> *certain*
> > > middlebox it *must* know the topology of the network (or 
> at least a
> > > sufficiently complete view on it).
> > 
> > People keep saying "must" in regard to directionality
> > and exporting topology to the application (beyond
> > the location of the middlebox), but they haven't made
> > a particularly strong case.  What would be helpful would
> > be a realistic example of a problem that can be solved
> > no other way along with an indication that the people
> > advocating this fully understand the implications of
> > interfacing with the routing system.  The advocacy
> > of this has been adamant in tone and casual in content,
> > and given how profoundly this proposal violates basic
> > IP network architecture principles I believe that it
> > needs a bit more respect.
> > 
> > Melinda
> 
> -- 
> Paul Sijben              Tel:+31 356874774 
> Lucent Technologies      Fax:+31 356875954
> Forward Looking Work     
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: "Mark Pietras" <[email-masked]>
Date: Thu, 9 Aug 2001 15:20:41 -0500

Okay, I (and others, I think) have made the assumption that once a packet arrives on side-A, it may or may not exit on side-B, but not exit again on side-A (without being routed back through by another device, i.e. a new packet to the middlebox).  To me it makes sense to leave that type of routing decision to a router, which to me the device currently defined is not.

If you're trying to solve the VoIP problem of preventing RTP packets from routing outside a LAN just to be routed right back in because the source and destination are on the same side, this should be solved by putting the CALL routing intelligence into the proxy server (or gatekeeper, or whatever) on the same side.  In this case, the middlebox is left out of the call altogether.

Mark.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
John LaCour
Sent: Thursday, August 09, 2001 11:17 AM
To: 'Mark Pietras'; [email-masked]
Subject: RE: [midcom] policy & duration

-John