Subject: AW: AW: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.tx t

From: Ruppelt Christian <[email-masked]>
Date: Thu, 13 Dec 2001 09:25:39 +0100

Hello Christian, 
I think it is not a good idea to change the timer to a value far below 30sec. 
The MG has to follow its retransmission procedure, because it has 
no knowledge about the status of the MGC1. The probability of a MGC1 
failure should be nearly 100% in case of  ServiceChange is send to 
the MGC2.    
Again my argument, the MGC2 knows definite about the failure of the MGC1  
Here the switchover (inclusive call states) could take place within 
milliseconds.

From a security point of view  we do not enter into a new discussion.
Apply the same security mechanisms for the second MGC than for the first.

It is very clear and well defined in the protocol what actions the MG should take: 
First:  nothing by its own with the exception to change the MG-MGC association 
Second: behave like a MG under the control of a MGC.

Christian   

> -----Urspr> üngliche Nachricht-----
> Von:	Christian Groves [SMTP:[email-masked]]
> Gesendet am:	Mittwoch, 5. Dezember 2001 14:42
> An:	Ruppelt Christian
> Cc:	'Tom-PT Taylor'; 'Padmaja Musti'; [email-masked]'
> Betreff:	Re: AW: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt
> 
> G'Day,
> 
> I have some trouble adding the text saying that a MG MAY accept a
> ServiceChange from an MGC which is not currently controlling it. It
> seems that the pretext of this discussion is for carrier grade solutions
> and that we don't want the MG to wait 30seconds before re-registering.
> The argument of the timer is implementation specific. If you have a
> carrier grade solution then change the timer to less than 30sec. A
> carrier grade solution probably wouldn't use UDP or TCP. I would 
> assume SCTP or MTP3 would be a more robust solution.
> 
> I make the assumption that the second MGC that takes over needs to know
> call state. If the MGCs have enough knowledge to swap state knowledge of
> ongoing calls to be able to control the MG then why can't the new MGC
> take over the MG connection of the old MGC. The MG will then not be
> aware of anychange.
> 
> Adding a "may" in this case does have security implications. Its another
> option that people will need to take into account and it will complicate
> the procedures that we have today. Its not clear what action the MG
> should take when it receives messages from the new MGC. Should
> connections established by the old MGC be cleared? etc? etc?
> 
> This definitely needs more description than just adding a single
> sentence.
> 
> Regards, Christian
> 
> Ruppelt Christian wrote:
> > 
> > Hello Tom,
> > Thanks for answering,
> > I agree with adding text in the way you proposed.
> > 
> > My question is now:
> > What has to be done to bring such a sentence into the megaco document?
> > I think it has to be agreed first on the mailing list.
> > 
> > >From a security point of view I do not see a contradiction to the
> > existing and described security mechanisms. This mechanisms have to
> > be supported within the current concept (primary MG and secondary MG)
> > and they have to be supported within the advanced concept.
> > The MG accepts ServiceChange from two MGCs with the same
> > security requirements and implementations than before.
> > 
> > Christian
> > 
> > > -----Urspr> üngliche Nachricht-----
> > > Von:  Tom-PT Taylor [SMTP:[email-masked]]
> > > Gesendet am:  Donnerstag, 29. November 2001 00:53
> > > An:   'Ruppelt Christian'; 'Padmaja Musti'; [email-masked]'
> > > Betreff:      RE: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt
> > >
> > > 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]'
> > > Subject: AW: [Megaco] Last Call Review: draft-ietf-megaco-h248v2-00.txt
> > >
> > >
> > > 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-----
> > > > Von:        Tom-PT Taylor [SMTP:[email-masked]]
> > > > 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
> > > >
> > > > 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,
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >     _______________________________________________
> > > >     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.
> > > > >
> > > > > 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)
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [email-masked]
> > > > http://www1.ietf.org/mailman/listinfo/megaco
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/megaco
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/megaco

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 17 Dec 2001 11:51:12 +1100

G'Day Christian,   (I feel like I'm talking to myself)

If the MGC2 can apply the same security mechanism as for the first then
it will appear as the first MGC. This would be completely hidden from
the MG ie. MGC2 would appear as MGC1. We don't need to add any new
mechanisms to handle this. I don't think the text in the protocol
precludes you from doing this.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 17 Dec 2001 11:51:12 +1100

Regards, Christian