Subject: RE: [Megaco] MEGACO mib - doubts

From: Raphael Tryster <[email-masked]>
Date: Tue, 6 Aug 2002 16:56:53 +0200

I don't know if Nuno's second posting was answered privately, but I am also
confused some of these definitions.  I would appreciate if someone could
correct those of my assumptions that are wrong.

medGwyGatewayConfigEntry is described as "Entry holding configuration
information about a group of Media Gateway Controllers sharing the same
signaling link."  I take this to mean that the list of primary and secondary
MGCs with which an MG can communicate, may be divided into several groups,
such that each group of MGCs sees the MG as having a different IP address
and port.  If this is true, why is it useful?

medGwyGatewayLinkName is described as "Name of this media gateway control
group."  Why does a group of MGCs need a name?

According to my interpretation above, each group represented by
MedGwyGatewayConfigEntry should relate to one or more entries in
medGwyGatewayControllerTable.  "An Entry in this Table is automatically
created when a manager creates an entry in the medGwyGatewayConfigTable".
Why "an" entry, rather than "one or more" entries?

Perhaps the same question in different phrasing:  How many objects of type
medGwyGatewayControllerEntry can exist for each unique set of INDEX {
medGwyGatewayId, medGwyGatewayLinkId }?

Raphael Tryster

	-----Original Message-----
	From:	Nuno Silva [SMTP:[email-masked]]
	Sent:	Monday, 10 June, 2002 1:14 AM
	To:	'Balasubramanian Pitchandi '; Nuno Silva; [email-masked] '
	Subject:	RE: [Megaco] MEGACO mib - doubts

	Hi Bala,

	 Many thanks for your answers.

	You say the signaling/transport link is the link between MGCs. My
first
	(wrong!) interpretation was that this was the link between a MG and
a MGC,
	for example, for Q.931 signaling backhaul. 

	 So, if I take your signaling link interpretation, I have several
doubts:

	A)is it possible to have more than 2 MGCs sharing the same link?
What for?
	How is exactly this signaling link defined?

	B) Are these (2 or more?)MGCs the ones that are SET by the NMS in
the
	medGwyGatewayControllerTable, for a given MG, or could be any
others?

	C) If this is the MG mib, why are there tables containing info about
the
	link between (2 or more?)MGCs? Shouldn't this be part of the MGC
mib?

	D)Also, this link is created by the manager for each MG - see
	medGwyLinkIdTable. Why is this done on the MG mib?

	 I think I haven't understood this "link" stuff ...

	 Thanks ahead. Nuno.

	-----Original Message-----
	From: Balasubramanian Pitchandi
	To: 'Nuno Silva'; [email-masked]
	Sent: 08-06-2002 01:37
	Subject: RE: [Megaco] MEGACO mib - doubts

	Hello,

	Please see my responses below [BP].

	Thanks,
	Bala
	 
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf
Of
	Nuno Silva
	Sent: Friday, June 07, 2002 7:35 AM
	To: [email-masked]
	Cc: Nuno Silva
	Subject: [Megaco] MEGACO mib - doubts

	Hi, 

	 I found the mib-03 draft hard to read. I have a few questions:

	1 - As far as I have understood this mib is referring only to the
MG.
	What
	about MGC mib?
	[BP] Yes, that's correct. I am working on putting a new MIB which
would
	have two different MIBs - one for Media Gateway and the other for
Media
	Gateway Controller.

	2 - medGwyGatewayConfigTable:
	 - the description of the medGwayGatewayConfigEntry object says
"Entry
	holding info about a group of MGCs sharing the same signalling
link". Is
	this signalling link the SIGTRAN link? Is it possible to have
several
	MGCs
	sharing the same signalling link? What for?
	[BP] It refers to any type of signaling that could exist between the
	MGCs. It could be SIGTRAN if that's the case in your implementation.

	3 - medGwyGatewayStatsTable:
	- the medGwyGatewayTransportNumLosses refers a transport link. Is
this
	the
	SIGTRAN link?
	[BP] Same as above.

	4- There's a reference in the medGwyPropertyProfileTable to package
	mibs. Is
	there any info about this?
	[BP] The package MIBs are still to be developed.

	5 - The distribution of functionality between MEGACO and SNMP is
also
	not
	very clear to me. It seems there is some overlapping. What do you
think?
	[BP] Yes, there is some overlapping. Its being worked on.

	 Thanks ahead. Nuno.

	PS: is there any other good source of information for understanding
the
	megaco mib? management requirements, other mails, ...

	[BP] Megaco MIB is a work in progress and I along with the help of
the
	Megaco community would come up with a new and improved version of
the
	MIB soon.

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

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

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 7 Aug 2002 17:58:05 +0200

Please see [FSRT] inline.

Raphael Tryster

	-----Original Message-----
	From:	Balasubramanian Pitchandi [SMTP:[email-masked]]
	Sent:	Tuesday, 06 August, 2002 6:18 PM
	To:	'Raphael Tryster'; 'Nuno Silva'; [email-masked]
	Subject:	RE: [Megaco] MEGACO mib - doubts

	Hi Raphael,

	I don't remember if I answered Nuno's queries then. Anyway, please
see my responses below marked as [BP].

	I have been delaying the new MIB draft for quite a while and I think
I should bring it out soon for comments. It would cover all this ambiguities
and make things clearer.

	 [FSRT] How different is the new draft?  Do you have an expected
date?

	Thanks,

	Bala

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Tuesday, August 06, 2002 10:57 AM
	To: Nuno Silva; 'Balasubramanian Pitchandi '; [email-masked] '
	Subject: RE: [Megaco] MEGACO mib - doubts

	I don't know if Nuno's second posting was answered privately, but I
am also confused some of these definitions.  I would appreciate if someone
could correct those of my assumptions that are wrong.

	medGwyGatewayConfigEntry is described as "Entry holding
configuration information about a group of Media Gateway Controllers sharing
the same signaling link."  I take this to mean that the list of primary and
secondary MGCs with which an MG can communicate, may be divided into several
groups, such that each group of MGCs sees the MG as having a different IP
address and port.  If this is true, why is it useful?

	[BP] medGwyGatewayConfigEntry actually represents a group of "Media
Gateways" that share the common signaling link. NOT the MGCs.
medGwyGatewayControllerEntry is the one which represents the group of MGCs.
It's a mistake in the MIB draft.

	medGwyGatewayLinkName is described as "Name of this media gateway
control group."  Why does a group of MGCs need a name?

	 [BP] Assuming that there can be many virtual MGs within one
physical MGs, this "LinkName" is used to identify them together. Its an
optional feature that the system administrator can choose to ignore.

	[FSRT] So I take it that medGwyGatewayLinkId and
medGwyGatewayLinkName are the same for all virtual MGs in the same physical
MG, while medGwyGatewayId is different for each virtual MG.  What about
medGwyGatewayIPAddress and medGwyGatewayPort?  Are they the same or
different for each virtual MG?

	[BP] I hope the above explanation would make this point clear.

	[FSRT] Afraid not.  My question below still stands.  If
MedGwyGatewayConfigEntry describes an MG, and medGwyGatewayControllerEntry
describes an MGC,  I would expect the relationship to be either many to many
(each MG can contact several MGCs, where each MGC may be in the primary or
secondary lists of several MGs) or one to many (with MGCs duplicated if they
are in the lists of more than one MG), but I do not understand how it can be
one to one.

	Perhaps the same question in different phrasing:  How many objects
of type medGwyGatewayControllerEntry can exist for each unique set of INDEX
{ medGwyGatewayId, medGwyGatewayLinkId }?

	Raphael Tryster 

	-----Original Message----- 
	From:   Nuno Silva [SMTP:[email-masked]] 
	Sent:   Monday, 10 June, 2002 1:14 AM 
	To:     'Balasubramanian Pitchandi '; Nuno Silva; [email-masked] '

	Hi Bala, 

	 Many thanks for your answers . 

	 Thanks ahead. Nuno. 

	-----Original Message----- 
	From: Balasubramanian Pitchandi 
	To: 'Nuno Silva'; [email-masked] 
	Sent: 08-06-2002 01:37 
	Subject: RE: [Megaco] MEGACO mib - doubts 

	Hello, 

	Please see my responses below [BP] . 

	Thanks, 
	Bala 
	  
	-----Original Message----- 
	From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of 
	Nuno Silva 
	Sent: Friday, June 07, 2002 7:35 AM 
	To: [email-masked] 
	Cc: Nuno Silva 
	Subject: [Megaco] MEGACO mib - doubts 

	Hi, 

	 

	 Thanks ahead. Nuno. 

	_______________________________________________ 
	Megaco mailing list 
	[email-masked] 
	https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  

	_______________________________________________ 
	Megaco mailing list 
	[email-masked] 
	https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 7 Aug 2002 17:58:05 +0200

Raphael Tryster

	-----Original Message-----
	From:	Balasubramanian Pitchandi [SMTP:[email-masked]]
	Sent:	Tuesday, 06 August, 2002 6:18 PM
	To:	'Raphael Tryster'; 'Nuno Silva'; [email-masked]
	Subject:	RE: [Megaco] MEGACO mib - doubts

	Hi Raphael,

	Thanks,

	Bala

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Tuesday, August 06, 2002 10:57 AM
	To: Nuno Silva; 'Balasubramanian Pitchandi '; [email-masked] '
	Subject: RE: [Megaco] MEGACO mib - doubts

	Raphael Tryster 

	-----Original Message----- 
	From:   Nuno Silva [SMTP:[email-masked]] 
	Sent:   Monday, 10 June, 2002 1:14 AM 
	To:     'Balasubramanian Pitchandi '; Nuno Silva; [email-masked] '

	Hi Bala, 

	 Thanks ahead. Nuno. 

	-----Original Message----- 
	From: Balasubramanian Pitchandi 
	To: 'Nuno Silva'; [email-masked] 
	Sent: 08-06-2002 01:37 
	Subject: RE: [Megaco] MEGACO mib - doubts 

	Hello, 

	Thanks, 
	Bala 
	  
	-----Original Message----- 

	Hi, 

	 

	 Thanks ahead. Nuno.

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 8 Aug 2002 20:44:13 +0200

Hello Bala,

I have been studying the MIB draft some more and have a few more questions.

1.	It seems to me that there should be 3 levels in
medGwyGatewayConfigTable, i.e. "SEQUENCE OF" should appear twice, but it
only appears once.  The 3 levels are:
- all the physical MGs managed by this manager,
- a single physical MG consisting of multiple virtual MGs,
- a single virtual MG.
Now, some of the fields in MedGwyGatewayConfigEntry could conceivably be
characteristic of either a physical or virtual MG, but some, most notably
medGwyGatewayResetStatistics, appear to have relevance only for a virtual
MG.  So my question is: where is the middle level?

2.	It is not clear to me how the MIB expresses the idea that each MG
can have a list of MGCs with which it may try to establish a control
association.  In particular, since medGwyGatewayControllerTable has only a
single row per { medGwyGatewayId, medGwyGatewayLinkId }, does each row
represent only the MGC with which the MG is currently communicating?  If so,
where is the other information?

3.	The statistics descriptor defines statistics at the call level, but
medGwyGatewayStatsTable supplies a different sets of MG-wide statistics
which I have not seen described in the standard.  What is the source for
supporting these particular statistics?

4.	medGwyInvalidControllerAddress: "This notification indicates that a
message was received from a controller that did not match any none valid
controller IPAddress".  Should "none" be "known"?

5.	I understand that medGwyInvalidControllerAddress is a type of error
that would be useful to report to a managing system, rather than to the
sending MGC, in order to guard against denial of service attacks.  The group
also includes medGwyInvalidTerminationId and medGwyInvalidPackageElement,
which are errors that might be found in commands from an MGC.  These are
just two out of a large number of errors that might occur in such commands,
and the MGC would receive an error response, so I wonder why these two were
singled out for special reporting to a managing system?

6.	Other items I would have expected to find here are not.  For
example, the base root package properties.

Raphael Tryster

	-----Original Message-----
	From:	Balasubramanian Pitchandi [SMTP:[email-masked]]
	Sent:	Tuesday, 06 August, 2002 6:18 PM
	To:	'Raphael Tryster'; 'Nuno Silva'; [email-masked]
	Subject:	RE: [Megaco] MEGACO mib - doubts

	Hi Raphael,

	Thanks,

	Bala

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Tuesday, August 06, 2002 10:57 AM
	To: Nuno Silva; 'Balasubramanian Pitchandi '; [email-masked] '
	Subject: RE: [Megaco] MEGACO mib - doubts

	[BP] Assuming that there can be many virtual MGs within one physical
MGs, this "LinkName" is used to identify them together. Its an optional
feature that the system administrator can choose to ignore.

	Raphael Tryster 

	-----Original Message----- 
	From:   Nuno Silva [SMTP:[email-masked]] 
	Sent:   Monday, 10 June, 2002 1:14 AM 
	To:     'Balasubramanian Pitchandi '; Nuno Silva; [email-masked] '

	Hi Bala, 

	 Thanks ahead. Nuno. 

	-----Original Message----- 
	From: Balasubramanian Pitchandi 
	To: 'Nuno Silva'; [email-masked] 
	Sent: 08-06-2002 01:37 
	Subject: RE: [Megaco] MEGACO mib - doubts 

	Hello, 

	Thanks, 
	Bala 
	  
	-----Original Message----- 

	Hi, 

	 

	 Thanks ahead. Nuno.

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 8 Aug 2002 20:44:13 +0200

Hello Bala,

Raphael Tryster

	-----Original Message-----
	From:	Balasubramanian Pitchandi [SMTP:[email-masked]]
	Sent:	Tuesday, 06 August, 2002 6:18 PM
	To:	'Raphael Tryster'; 'Nuno Silva'; [email-masked]
	Subject:	RE: [Megaco] MEGACO mib - doubts

	Hi Raphael,

	Thanks,

	Bala

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Tuesday, August 06, 2002 10:57 AM
	To: Nuno Silva; 'Balasubramanian Pitchandi '; [email-masked] '
	Subject: RE: [Megaco] MEGACO mib - doubts

	Raphael Tryster 

	-----Original Message----- 
	From:   Nuno Silva [SMTP:[email-masked]] 
	Sent:   Monday, 10 June, 2002 1:14 AM 
	To:     'Balasubramanian Pitchandi '; Nuno Silva; [email-masked] '

	Hi Bala, 

	 Thanks ahead. Nuno. 

	-----Original Message----- 
	From: Balasubramanian Pitchandi 
	To: 'Nuno Silva'; [email-masked] 
	Sent: 08-06-2002 01:37 
	Subject: RE: [Megaco] MEGACO mib - doubts 

	Hello, 

	Thanks, 
	Bala 
	  
	-----Original Message----- 

	Hi, 

	 

	 Thanks ahead. Nuno.

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 12 Aug 2002 13:59:16 +0200

Hello Bala,

	Thanks for your answers, but I'm still quite confused.  Please see
[FSRT].

	Raphael Tryster

	-----Original Message-----
	From:	Balasubramanian Pitchandi [SMTP:[email-masked]]
<mailto:[SMTP:[email-masked]]> 
	Sent:	Monday, 12 August, 2002 12:46 AM
	To:	'Raphael Tryster'; [email-masked] <mailto:[email-masked]> 
	Subject:	RE: [Megaco] MEGACO mib - doubts

	Hello Raphael,

	Thanks for your comments. Please see my responses below [BP].

	Thanks,

	Bala

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]>  
	Sent: Thursday, August 08, 2002 2:44 PM
	To: [email-masked]; <mailto:[email-masked];>  [email-masked]
<mailto:[email-masked]> 
	Subject: RE: [Megaco] MEGACO mib - doubts

	Hello Bala, 

	I have been studying the MIB draft some more and have a few more
questions. 

	1.     It seems to me that there should be 3 levels in
medGwyGatewayConfigTable, i.e. "SEQUENCE OF" should appear twice, but it
only appears once.  The 3 levels are:
	- all the physical MGs managed by this manager,
	- a single physical MG consisting of multiple virtual MGs,
	- a single virtual MG.
	Now, some of the fields in MedGwyGatewayConfigEntry could
conceivably be characteristic of either a physical or virtual MG, but some,
most notably medGwyGatewayResetStatistics, appear to have relevance only for
a virtual MG.  So my question is: where is the middle level?

	[BP] The middle level can be derived from the same table, by way of
intelligently querying the agent (doing a GET-ROW of all the medGwyLinkIds
in a mediaGwyId). I would like to keep the MIB as simple as possible and not
have duplicate information (which can be derived).

	[FSRT] Let me see if I have this straight.  A
medGwyGatewayConfigTable represents the idea that a manager sees multiple
physical MGs,  Each physical MG may contain several virtual MGs.  There is a
one-to-one correspondence between a SignallingLink and a virtual MG.
Different physical MGs have different values for the medGwyGatewayId index.
Different virtual MGs in the same physical MG have the same value for
medGwyGatewayId, but different values for medGwyGatewayLinkId.  Is this
correct?

	If so, then I do not understand the description of
medGwyGatewayConfigEntry: "Entry holding configuration information about a
group of Media Gateway Controllers sharing the same signaling link."   Even
after deleting the word "controllers", which you said is an error, I would
think that each entry describes a SINGLE virtual MG, which corresponds to a
single signaling link.  If you talk about a GROUP of virtual MGs sharing the
same signaling link, then it seems you are describing an additional level in
the hierarchy: a manager sees several physical MGs, each of which may have
several signaling links, and each of those signaling links may be shared by
several virtual MGs.  But in that case, you do not have an index to identify
an individual virtual MG!

	2.     It is not clear to me how the MIB expresses the idea that
each MG can have a list of MGCs with which it may try to establish a control
association.  In particular, since medGwyGatewayControllerTable has only a
single row per { medGwyGatewayId, medGwyGatewayLinkId }, does each row
represent only the MGC with which the MG is currently communicating?  If so,
where is the other information?

	[BP] The new MIB draft would add a new object to indicate which MGC
that the MG is currently communicating with (i.e, the primary MGC), 

	[FSRT] I was under the impression that these two concepts are not
the same.  The primary MGC is the one that the MG has been PROVISIONED to
contact first.  If it fails to contact the primary, it will try its
provisioned list of secondary MGCs, or it may be redirected by one of those
MGCs to another one of which it had no previous knowledge.  In any event, if
it establishes a control association with a MGC that is not the primary one,
this does not change the identity of the provisioned primary MGC.  So, if
this is correct, the primary MGC is not necessarily the one with which the
MG is currently communicating.

	[BP] if that is what you are asking about. The
medGwyGatewayConfigTable would contain all the MGs that are provisioned in
the MGC,

	[FSRT] MGs provisioned in the MGC?  Someone asked a question about
that in the email list yesterday, but I don't recall anything in the
standard about it.  Is this MIB intended to support an agent residing in the
MG, or in the MGC, or both?

	[BP] indexed by the SignallingLink (LinkId) and the mediaGwyId. 

	[FSRT] Is there a reason you reversed the order of the indexes?

	[FSRT] My main problem with medGwyGatewayControllerTable is that I
do not see how it supports the notion that an MG has a primary MGC and a
list of secondary MGCs which it may contact.  medGwyGatewayControllerEntry
is indexed by medGwyGatewayId and medGwyGatewayLinkId, which (if I am
correct above) means there is ONE medGwyGatewayControllerEntry for each
virtual MG.  But I am looking for a LIST of MGCs per virtual MG.  Where is
it?  And if medGwyGatewayControllerEntry is neither the current MGC nor the
list of primary and secondary, that what exactly does it represent?

	3.     The statistics descriptor defines statistics at the call
level, but medGwyGatewayStatsTable supplies a different sets of MG-wide
statistics which I have not seen described in the standard.  What is the
source for supporting these particular statistics?

	[BP] Are you referring to TransportXXXXX? 

	[FSRT] Not only.  All the statistics in this table are per-MG, and I
have not seen them in the standard.  On the other hand, the standard does
define per-termination octet and packet counts, and I do not see them in the
MIB.  Per your answer to #6 below, perhaps I should expect to see them in a
package MIB.

	[BP] They originally are from RMON MIBs. I am still deliberating to
myself on to whether we need those statistics or not. I would probably have
it now and later depending on folks' views, we could take a decision.

	4.     medGwyInvalidControllerAddress: "This notification indicates
that a message was received from a controller that did not match any none
valid controller IPAddress".  Should "none" be "known"?

	[BP] Yes.

	5.     I understand that medGwyInvalidControllerAddress is a type of
error that would be useful to report to a managing system, rather than to
the sending MGC, in order to guard against denial of service attacks.  The
group also includes medGwyInvalidTerminationId and
medGwyInvalidPackageElement, which are errors that might be found in
commands from an MGC.  These are just two out of a large number of errors
that might occur in such commands, and the MGC would receive an error
response, so I wonder why these two were singled out for special reporting
to a managing system?

	[BP] The Errors that are available in the current list are not
exhaustive. The new MIB would choose a more clear approach with respect to
the notifications.

	[BP] I am coming up with some of the package MIBs (atleast the ones
that are in the H.248v2). I would prepare a framework for future authors to
come up with the MIBs when they come up with new packages. 

	[FSRT] Do you have a target date for publishing the package MIBs?

7.	[FSRT] medGwyTerminationsTable: In the Description clause it says:
"...The number of entries equals to the total number of terminations for all
contexts in a gateway". Would it be more correct to change this to: "..The
number of entries equals the total number of physical terminations in all
managed gateways." ?  By the way, why is medGwyGatewayLinkId not used as an
index in this table?  There doesn't seem to be a way of associating a
termination with a specific virtual MG.

	Thank you,

	Raphael Tryster

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 12 Aug 2002 13:59:16 +0200

Hello Bala,

	Raphael Tryster

	-----Original Message-----

	Hello Raphael,

	Thanks,

	Bala

	-----Original Message-----

	Hello Bala, 

	[BP] Yes.

	Thank you,

	Raphael Tryster