Subject: RE: [midcom] policy & duration

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Aug 2001 06:43:09 -0700

Melinda,

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 6:23 AM
> To: Paul Sijben
> Cc: midcom
> Subject: Re: [midcom] policy & duration
> 
> 
> > 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

Is enough to mention any type of assymetric routing?

> and given how profoundly this proposal violates basic
> IP network architecture principles 

can you elaborate on that? "Violates the basic...". When a device knows
topological information it violates the basic principle? 

thanks,

Reinaldo

I believe that it 
> needs a bit more respect.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 9 Aug 2001 09:54:02 -0400

> Is enough to mention any type of assymetric routing?

No - I'm not disputing that there are routing decisions
to be made.  I'm trying to understand the benefit of pulling
the midcom agent into the routing system, along with all that
it implies.

> topological information it violates the basic principle? 

No, but when an application knows the location of network-layer
devices and makes routing decisions based on that knowledge,
you by definition lose all benefits of the fundamental design
principles underlying IP.  You lose robustness in the face of
routing changes, you lose scalability, fate-sharing is undone,
and so on.  You need to be thinking about what happens when routes
change, how routing tables would be exported to midcom agents, and
so on. 

Melinda

---

From: Paul Sijben <[email-masked]>
Date: Thu, 09 Aug 2001 16:07:01 +0200

Melinda,

you wrote:
> You need to be thinking about what happens when routes

OK, this line of argument is exactly why QoS should be in scope for
MIDCOM. Because if you want QoS, you are in major trouble anyway when the
route changes. You must know this at application level because of the cost
(real $$) of transporting a QoS flow.

In the cases where that is not necessary to know you do not need to see
this in the view of the network tolopogy you (as a MA) are given.

Paul

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 9 Aug 2001 14:19:55 -0400

> MIDCOM. 

QoS is not in scope.  This is not negotiable.

Melinda