Subject: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Nov 2001 15:56:31 -0500

This is to announce an extended WG Last Call for the H.248v2 document,
posted as draft-ietf-megaco-h248v2-00.txt.  I propose to conduct this review
by stages, to focus discussion.  In particular, I am asking for comments on
the document through the end of section 6, with a view to identifying and
resolving any issues by the end of next week.

New items for H.248v2 (as opposed to IG items) are:

 - final bullet in 6.1.1, indicating that context properties can be added by
packages
 - context-related text in 6.2.3

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

---

From: Ruppelt Christian <[email-masked]>
Date: Fri, 23 Nov 2001 09:49:07 +0100

stressing the MGC-failure once more, because I think this is an important topic
and there is a chance to improve megaco_v2.  
 
If one MGC (e.g. MGC1) fails,  why is the Handoff only controlled by
the MG (slave)?
Why is it explicit forbidden for the controller (master)  e.g. MGC2 to activate the 
Handoff?
Only in case of MGC1 knows of it's impending death (which is the unlikely case) 
the Handoff is allowed by the dying controller.
With this restriction the protocol directs the boxes to be less reliable and 
less performant. 

Christian     

	-----Ursprüngliche Nachricht-----
	Von:	Ruppelt Christian [SMTP:[email-masked]]
	Gesendet am:	Donnerstag, 22. November 2001 10:48
	An:	[email-masked]
	Betreff:	[Megaco] MGC2  twiddling his thumbs

	some thoughts regarding MGC failure: 
	assumed we have one MG controlled by MGC1(primary) and MGC2(secondary).
	Now MGC1 fails (a ServiceChange with method = Handoff could not be send by 
	MGC1). 

	As I understand megaco, MGC2 has now to wait about 30 seconds to get the
	ServiceChange command from the MG twiddling his thumbs. 
	(contradiction to the master slave paradigma) 

	It is out of scope of megaco but a carrier grade solution have to ensure 
	that  in case of MGC1 failure the context-data from MGC1 have to be available 
	somehow at MGC2.
	That means also the failure of MGC1 could easily be known by MGC2 within
	a few milliseconds.

	Following this and the megaco Master/slave paradigma 
	a ServiceChange with method = Handoff  send by MGC2 should be allowed 
	by megaco to improve the performance of this scenario.

	comments are welcome 
	Christian  

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

> -----Ursprüngliche Nachricht-----
> Von:	Tom-PT Taylor [SMTP:[email-masked]]
> Gesendet am:	Mittwoch, 21. November 2001 21:57
> An:	[email-masked]'
> Betreff:	[Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt
> 
> This is to announce an extended WG Last Call for the H.248v2 document, posted as draft-ietf-megaco-h248v2-00.txt.  I propose to conduct this review by stages, to focus discussion.  In particular, I am asking for comments on the document through the end of section 6, with a view to identifying and resolving any issues by the end of next week.
> 
>  - final bullet in 6.1.1, indicating that context properties can be added by packages 

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

---

From: Ruppelt Christian <[email-masked]>
Date: Fri, 23 Nov 2001 09:49:07 +0100

Christian     

	-----Ursprüngliche Nachricht-----
	Von:	Ruppelt Christian [SMTP:[email-masked]]
	Gesendet am:	Donnerstag, 22. November 2001 10:48
	An:	[email-masked]
	Betreff:	[Megaco] MGC2  twiddling his thumbs

	comments are welcome 
	Christian

---

From: Padmaja Musti <[email-masked]>
Date: Fri, 23 Nov 2001 16:16:36 +0530

Hi,
I think that is a good point. Since MGC2 comes to know of MGC1 
failure sooner than MG, it should be allowed to takeover. 
Since MGC2 is configured as a secondary MGC at the MG,
it is safe to accept the Handoff from MGC2. This will reduce
the MTTR and so higher availability.
regards,
Padma

-----Original Message-----
From: Ruppelt Christian [mailto:[email-masked]]
Sent: Friday, November 23, 2001 2:19 PM
To: 'Tom-PT Taylor'; [email-masked]'
Subject: AW: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt

stressing the MGC-failure once more, because I think this is an important
topic
and there is a chance to improve megaco_v2.  
 
If one MGC (e.g. MGC1) fails,  why is the Handoff only controlled by
the MG (slave)?
Why is it explicit forbidden for the controller (master)  e.g. MGC2 to
activate the 
Handoff?
Only in case of MGC1 knows of it's impending death (which is the unlikely
case) 
the Handoff is allowed by the dying controller.
With this restriction the protocol directs the boxes to be less reliable and

less performant. 

Christian     

	-----Ursprüngliche Nachricht-----
	Von:	Ruppelt Christian [SMTP:[email-masked]]
	Gesendet am:	Donnerstag, 22. November 2001 10:48
	An:	[email-masked]
	Betreff:	[Megaco] MGC2  twiddling his thumbs

	some thoughts regarding MGC failure: 
	assumed we have one MG controlled by MGC1(primary) and
MGC2(secondary).
	Now MGC1 fails (a ServiceChange with method = Handoff could not be
send by 
	MGC1). 

	As I understand megaco, MGC2 has now to wait about 30 seconds to get
the
	ServiceChange command from the MG twiddling his thumbs. 
	(contradiction to the master slave paradigma) 

	It is out of scope of megaco but a carrier grade solution have to
ensure 
	that  in case of MGC1 failure the context-data from MGC1 have to be
available 
	somehow at MGC2.
	That means also the failure of MGC1 could easily be known by MGC2
within
	a few milliseconds.

	Following this and the megaco Master/slave paradigma 
	a ServiceChange with method = Handoff  send by MGC2 should be
allowed 
	by megaco to improve the performance of this scenario.

	comments are welcome 
	Christian

---

From: Padmaja Musti <[email-masked]>
Date: Fri, 23 Nov 2001 16:16:36 +0530

Hi,

-----Original Message-----
From: Ruppelt Christian [mailto:[email-masked]]
Sent: Friday, November 23, 2001 2:19 PM
To: 'Tom-PT Taylor'; [email-masked]'
Subject: AW: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt

less performant. 

Christian     

	-----Ursprüngliche Nachricht-----
	Von:	Ruppelt Christian [SMTP:[email-masked]]
	Gesendet am:	Donnerstag, 22. November 2001 10:48
	An:	[email-masked]
	Betreff:	[Megaco] MGC2  twiddling his thumbs

	comments are welcome 
	Christian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 23 Nov 2001 08:55:38 -0500

I have colleagues who were trying to get some action on this point last
year.  The problem is that allowing for this possibility changes the process
structure of the stack.  For connection-oriented protocols (e.g. TCP) the MG
has to become a listener.  That proposal met with fairly strong resistance.

-----Original Message-----
From: Padmaja Musti [mailto:[email-masked]]
Sent: Friday, November 23, 2001 5:47 AM
To: 'Ruppelt Christian'; Taylor, Tom-PT [CAR:B800:EXCH];
[email-masked]'
Subject: RE: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt

Hi,

-----Original Message-----
From: Ruppelt Christian [mailto:[email-masked]]
Sent: Friday, November 23, 2001 2:19 PM
To: 'Tom-PT Taylor'; [email-masked]'
Subject: AW: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt

less performant. 

Christian     

	-----Ursprüngliche Nachricht-----
	Von:	Ruppelt Christian [SMTP:[email-masked]]
	Gesendet am:	Donnerstag, 22. November 2001 10:48
	An:	[email-masked]
	Betreff:	[Megaco] MGC2  twiddling his thumbs

	comments are welcome 
	Christian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 23 Nov 2001 08:55:38 -0500

-----Original Message-----
From: Padmaja Musti [mailto:[email-masked]]
Sent: Friday, November 23, 2001 5:47 AM
To: 'Ruppelt Christian'; Taylor, Tom-PT [CAR:B800:EXCH];
[email-masked]'

Hi,

-----Original Message-----
From: Ruppelt Christian [mailto:[email-masked]]
Sent: Friday, November 23, 2001 2:19 PM
To: 'Tom-PT Taylor'; [email-masked]'
Subject: AW: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt

less performant. 

Christian     

	-----Ursprüngliche Nachricht-----
	Von:	Ruppelt Christian [SMTP:[email-masked]]
	Gesendet am:	Donnerstag, 22. November 2001 10:48
	An:	[email-masked]
	Betreff:	[Megaco] MGC2  twiddling his thumbs

	comments are welcome 
	Christian

---

From: Ruppelt Christian <[email-masked]>
Date: Mon, 26 Nov 2001 10:59:06 +0100

Hi Tom,
UDP is an allowed alternative within megaco RFC;
so, why artificially reduce reliabilty here? 

By allowing a second connection between MG and MGC2 
for maintenance reasons we could solve the problem
for connection oriented transport protocols. 

Anyway,  constraints of TCP or SCTP should not 
influence the flexibility of megaco. 

Christian

> -----Urspr> üngliche Nachricht-----
> Gesendet am:	Freitag, 23. November 2001 14:56
> An:	'Padmaja Musti'; 'Ruppelt Christian'; [email-masked]'
> Betreff:	RE: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt
> 
> > Betreff:	[Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt> 
> >

---

From: Ruppelt Christian <[email-masked]>
Date: Mon, 26 Nov 2001 10:59:06 +0100

Hi Tom,

Christian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 28 Nov 2001 18:52:55 -0500

It's not totally artificial.  The problem is that when we agreed to support
multiple transport protocols, we had to have a mechanism for agreement
between the MG and MGC on which one to use.  That mechanism was to require
the MGC to support both UDP and TCP and let the MG decide the choice.

We have to protect this basic mechanism.  So our problem is to allow MG
designers (the ones most affected by this discussion) to go beyond the
current limitations if they wish, without forcing it on implementations done
by the existing rules.  I suppose one possibility would be to simply add
text saying that an MG MAY accept a ServiceChange from an MGC which is not
currently controlling it.  We would have to accompany this with a serious
discussion of the security implications.

-----Original Message-----
From: Ruppelt Christian [mailto:[email-masked]]
Sent: Monday, November 26, 2001 4:59 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Padmaja Musti'; Ruppelt Christian;
[email-masked]'

Hi Tom,

Christian

> >  - final bullet in 6.1.1, indicating that context properties can be
added
> by packages

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 28 Nov 2001 18:52:55 -0500

-----Original Message-----
From: Ruppelt Christian [mailto:[email-masked]]
Sent: Monday, November 26, 2001 4:59 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Padmaja Musti'; Ruppelt Christian;
[email-masked]'

Hi Tom,

Christian

added