Hi, Offer and All:

With respect to AT&T's proposal (D.225), 3Com's views can be summarized as follows:

1. Support distributed GK architecture (not the hierarchical model) 2. Treat the GK as a monolithic entity 3. Reduce the number of GK subcomponents into two categories: Registration/Pre-call (e.g., RAS) and Call Related issues (e.g., Q.931/932, H.245)

If we are in agreement about those three items, we can start bringing follow-up contributions along those lines.

With respect to hierarchical model, I'd like to point out that BEs that perform the "clearing house" functions work almost in a hierarchical fashion. If necessary, we can also examine whether the extension that will be made in H.323 protocol to enhance the reliability/robustness of the GK of the distributed model is also good for the hierarchical model.

I also plan to attend the conf call on January 6.

Happy Holidays and have a wonderful New Year!!

Best regards, Radhika R. Roy, AT&T +1 732 420 1580 rrroy@att.com

-----Original Message----- From: Offer Pazy [SMTP:Offer_Pazy@EUR.3COM.COM] Sent: Wednesday, December 15, 1999 7:21 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: [Robustness] A couple comments on D.225

Hello,

I hope that this is the right forum, procedure and timing for commenting on the D.225 document. If not, please use moderate flames only....

In general, I like the models presented and I think they serve a useful starting point. I would like to offer two simplifications:

1. Distributed Vs hierarchical architectures:

I don't see the value of having a special hierarchical case. As suggested in D.225, we must avoid single point of failures. The node at the top of the diagram (figure 7) is such a point unless we introduce redundancy for it as well. When we do so, we go back to the general distributed case where each node has a primary GK of a zone plus zero or more backup GKs for other zones. My view is that describing the model in this way is simpler than having two distinct cases,

2. D.225 proposes that the three internal "components" of a GK should be

exposed and that redundancy mechanisms should be defined for them. I wonder if we should not keep this as an implementation issue. After all, GKs are defined in H.323 as containing all these three components and there was no intention (I believe) to force end-points to distinguish between a failed GK and the failure of one of its subcomponents. To formalize such granularity would require us to answer questions such as: What happens if the Q.931 component of GK A fails but its H.245 component is running OK, and the backup of the Q.931 of GK A resides with GK B whose RAS component has failed? Or, what happens when an endpoint is registered with GK A but uses GK B (GK-routed) as the originating GK when the Q.931 component of A has failed? etc. etc. Clearly this is a complex problem to solve.

Instead I believe we should concentrate on treating the GK as a monolithic entity which 1) has fail-stop semantics and 2) a backup entity is backing up the GK as a whole as opposed to having a backup for each subcomponent. From the standard and protocols stand-point this will suffice. Clearly, implementors will have to invest efforts in designing their GK architectures in the most fault tolerant manner (and may use some of the ideas presented in D.225), but this should really be out of scope for the standard as long as the semantics of a failed GK are clearly defined.

A slightly different way to look at the proposal in D.225 is to reduce the number of GK subcomponents from three (RAS, Q.931, H.245) to two: Registration issues and "a particular call"-related issues. As can be noticed, this idea does not just decrease the granularity (which by itself simplifies things), but also shifts the focus of the model from that of an implementation view to a more behavioral view. It can be argued that H.323 endpoints already have to distinguish between the registration process and failures and the process of call establishment and control.

Offer