Subject: RE: [midcom] Re: draft-sct-midcom-megaco-01.txt

From: "Sanjoy Sen"<[email-masked]>
Date: Fri, 26 Apr 2002 11:29:45 -0500

I think requirements 2.2.7 and 2.1.3, as stated, are quite different. 2.1.3
does not say anything about overlapping resources or policy rules. It just
says that the protocol must allow multiple agent access a Middlebox. Megaco
allows that through the Virtual MG mechanism.

The other requirement (2.2.7) talks about the protocol not precluding
overlapping rulesets (subset or superset). Well, Megaco does not, as long as
we keep the ruleset separate from Terminations or other like Megaco entities
(and somehow link them back through their attributes). This is the essence
of our model shown in Appendix. This new layer of abstraction allows us to
manipulate the rulesets without any modification of the behavior of the base
protocol. Again, Megaco does not preclude this from happening in any ways.

Thanks for your comments,
Sanjoy 

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 1:07 PM
> To: [email-masked]'
> Subject: [midcom] Re: draft-sct-midcom-megaco-01.txt
> 
> 
> As with some of the other analysis, this analysis treats 
> partitioning as a 
> solution to the multiple manager problem.  This does not meet the 
> requirements as stated.  (It may be a compromise we are 
> willing to accept, 
> but should be described as partially met or not met, not 
> claimed to be 
> completely met.)
> With apologies for appearing to be hammering on this 
> particular author (as 
> they are not the only ones to have made this leap), I will 
> quote from their 
> document:
> 
>   ô2.2.7.
> 
>     The Midcom protocol must not preclude multiple authorized agents
>     from working on the same policy rule.ö
> 
>       In case the Megaco state machine on the Middle Box is decoupled
>       from the Middle Box policy rule management, this requirement is
>       met with local policies on the Middle Box.
> 
>   ô2.1.3.
> 
>     The Midcom protocol must allow a middlebox to communicate 
> with more
>     than one Midcom agent simultaneously.
> 
>     There may be multiple instances of a single application 
> or multiple
>     applications desiring service from a single middlebox, and differ-
>     ent agents may represent them.  The protocol design must not pre-
>     clude the ability to do so.ö
> 
>       Megaco has the concept of Virtual Media Gateways (VMG) within a
>       single physical MG that allows multiple MGCs communicate
>       simultaneously with the same MG, sharing resources in a 
> conflict-
>       free manner.
> 
>   3. Virtual Media Gateways: A physical MG can be partitioned into
>     multiple virtual MG's allowing multiple Controllers to 
> interact with
>     disjoint sets of Contexts/Terminations within a single physical
>     device.
> 
> So we see on the one hand that working with multiple agents 
> is a local 
> matter, and on the other that it is to be dealt with by VMGs. 
>  However, if 
> it were actually practical to deal with it purely as a local 
> matter, we 
> would not have included it as a protocol requirement.  And 
> the description 
> of the VMG requires complete partition of scope, while it is 
> clear to me at 
> least that the intent of the requirement is to allow 
> overlapping scopes.
> 
> Yours,
> Joel M. Halpern
> 
> PS: There is a reasonable claim that the determinism 
> requirement and the 
> overlapping control requirement can not both be met as 
> written.  If that is 
> your view, then describe the protocol as partially meeting 
> each requirement 
> and we as a working group may decide to accept such.  Noone 
> is being asked 
> to claim to do the impossible.  Accurate descriptions are 
> much more helpful.
> 
>      
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
>