Subject: RE: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to re-synch resolves PO issue?

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Mon, 29 Sep 2003 12:32:22 +0200

Brian,

only one remark/question: 

according to Q.703 the MTP3 primitives "Local processor outage" and "Local processor recovered" are flagged a relevant only in case of using the national option of "latching processor outage". 

Which SS7 networks do really use this national option? (SS7 Network operators (not implementors!) step forward now!)
It's definitely not used in Europe.

MTP3 without using this national option can very well do without receiving "remote processor outage" and "remote processor recovered"

It might turn out that having the PO in M2PA is an optional procedure only relevant when latching is required.

greetings

HannsJuergen

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, September 29, 2003 12:21 PM
> To: Schwarzbauer Hanns Juergen
> Cc: 'Tom George'; [email-masked]
> Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR
> used to re-synch resolves PO issue?
> 
> 
> Schwarzbauer,
> 
> Perhaps not, but wihout PO M2PA will no longer meet the framework
> objectives, and will have to sepcify an entire state machine.  It
> will not provide the MTP2/MTP3 interface unaffected as described in
> Section 1.6 and will basically be a brand new link type that will
> require ITU and National standardization in SS7 before it can be
> connected to an MTP 3.  That rather defeats the purpose of M2PA
> entirely.
> 
> Gee, M2PA wouldn't even be compatible with M2UA.
> 
> Great idea... technically incorrect, but a great idea nevertheless.
> 
> --brian
> 
> Schwarzbauer Hanns Juergen wrote:                             
>                 (Mon, 29 Sep 2003 10:05:00)
> > Brian,
> > 
> > obviously there are some more supporters for removing PO now, if I
> > interpreted recent mails correctly.  So just referring to previous
> > discussions doesn't meet the point.
> > 
> > 
> > HannsJuergen
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Monday, September 29, 2003 9:57 AM
> > > To: Schwarzbauer Hanns Juergen
> > > Cc: 'Tom George'; [email-masked]
> > > Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on 
> stream 1 and LSPR
> > > used to re-synch resolves PO issue?
> > > 
> > > 
> > > Schwarzbauer,
> > > 
> > > I think we had these disucssions many times in the last 
> several years,
> > > long before Last Call.  What is so different now?
> > > 
> > > --brian
> > > 
> > > Schwarzbauer Hanns Juergen wrote:                             
> > >                 (Mon, 29 Sep 2003 09:51:44)
> > > > Brian,
> > > > 
> > > > to be honest, what M2PA is currently looking like is close 
> > > to a wire (except
> > > > that it filters out FISUs)
> > > > 
> > > > HannsJuergen
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Monday, September 29, 2003 9:29 AM
> > > > > To: Schwarzbauer Hanns Juergen
> > > > > Cc: 'Tom George'; [email-masked]
> > > > > Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on 
> > > stream 1 and LSPR
> > > > > used to re-synch resolves PO issue?
> > > > > 
> > > > > 
> > > > > Schwarzbauer,
> > > > > 
> > > > > Lets get rid of data retrieval, reporting link status changes,
> > > > > and the link alignment procedure and we can really 
> simplify M2PA:
> > > > > down to a wire. ;)
> > > > > 
> > > > > --brian
> > > > > 
> > > > > Schwarzbauer Hanns Juergen wrote:                             
> > > > >                 (Mon, 29 Sep 2003 09:01:22)
> > > > > > Tom,
> > > > > > 
> > > > > > I definitly support the removal of PO from M2PA!
> > > > > > 
> > > > > > greetings
> > > > > > 
> > > > > > HannsJuergen
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Tom George [mailto:[email-masked]]
> > > > > > > Sent: Friday, September 26, 2003 11:18 PM
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on 
> > > > > stream 1 and LSPR
> > > > > > > used to re-synch resolves PO issue?
> > > > > > > 
> > > > > > > 
> > > > > > > Removing support for PO would simplify the draft 
> in some ways.
> > > > > > > 
> > > > > > > If anybody thinks this is not the way to go, now 
> would be a 
> > > > > > > good time to 
> > > > > > > speak up.
> > > > > > > 
> > > > > > > tomG.
> > > > > > > 
> > > > > > > [email-masked] wrote:
> > > > > > >    [...]
> > > > > > > > Maybe we should reconsider M2PA's support of processor 
> > > > > > > outage, and instead
> > > > > > > > just fail the link
> > > > > > > > like other HSLs do.
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > 
> > > > > > > > Jeff
> > > > > > >    [...]
> > > > > > > 
> > > > > > > 
> > > > > > > -- 
> > > > > > > * Tom George       PB7-24001 (near B-21)      
> > > > > > > [email-masked]  *
> > > > > > > * 972-519-3168   Intranet:  
> > > > > > > http://www.ssd.usa.alcatel.com/~tgeorge/  *
> > > > > > > *   I actively disclaim speaking for Alcatel.  I do not 
> > > > > > > purport to    *
> > > > > > > *   advertise or represent its position, operations, or 
> > > > > > > activities.   *
> > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Sigtran mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > 
> > > > > -- 
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > > 
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 

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

---

From: "Richard Adams" <[email-masked]>
Date: Mon, 29 Sep 2003 12:48:30 +0200

Brian and Hanns-Juergen,
The national option of latching LPO to RPO was defined by the UK so that a changeover was committed
and completed on reception of RPO. PO was only defined for MTP L2 if L2 lost touch with its L3. So the 
only reason for L3 telling its local L2 to set PO was to ensure the changeover occurred.
If everyone agrees that  M2PA won't lose touch with its overlying layer, then PO isn't necessary at all.
And since MTP3 won't ever invoke LPO, because RPO will not be received, the interface between MTP3
and M2PA will not be broken.
To my mind, removing the PO procedures from M2PA will simplify M2PA considerably.
Kind regards,
Dick Adams.

	-----Original Message----- 
	From: Schwarzbauer Hanns Juergen [mailto:[email-masked]] 
	Sent: Mon 29/09/2003 12:32 
	To: [email-masked]'; Schwarzbauer Hanns Juergen 
	Cc: 'Tom George'; [email-masked] 
	Subject: RE: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to re-synch resolves PO issue?

	Brian,

	

	
	greetings
	
	HannsJuergen