Subject: RE: FW: [Sigtran] M2PA Last Call Comment

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Fri, 25 Jul 2003 09:41:38 +0200

Tom,

I sent an answer to your mail friday last week, albeit I received it back from the exploder, I never got a response on it, so I'm repeating parts of that mail.

========================
 Question: does STP A care about the fact that STPB has links according to Q.2140? 
 Answer: NO, NOT AT ALL, STP A operator might not even know that STP B has Q.2140 links.  

        +-----------+                 +-----------+
   Q.703|           |                 |           |   Q.2140
  ------+           |                 |           +--------
        |           |       Q.703     |           |
        | STP A     +-----------------+   STP B   |
        |           |                 |           |
   Q.703|           |                 |           |   Q.2140
  ------+           |                 |           +--------
        |           |                 |           |
        +-----------+                 +-----------+

Let's go to an IP based link between STP A and STP B

Question: should STP A care about the fact that STP B has links according to Q.2140?
Answer: I see no necessity to deviate from ANSI and ITU-T.

        +-----------+                 +-----------+
   Q.703|           |                 |           |   Q.2140
  ------+           |                 |           +--------
        |           |       M2PA      |           |
        | STP A     +-----------------+   STP B   |
        |           |                 |           |
   Q.703|           |                 |           |   Q.2140
  ------+           |                 |           +--------
        |           |                 |           |
        +-----------+                 +-----------+

If STP A wants to prove, he should do that and STP B has to support STP A in that procedure and vice versa.
But I see no necessity why both sides should perform similiar. 

In all other cases STP A would have to be informed if e.g. STP-B migrates from pure Q.703 to pure Q.2140 and that's not acceptable.
=========================

My point is that using or not using the proving of M2PA is independent from the flavour of MTP level 2 procedure used on the TDM side of the SG. According to Figure 2 in draft 9 there is an MTP 3 on top, effectively decoupling both sides.

greetings 

HannsJuergen

> -----Original Message-----
> From: Tom George [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 10:28 PM
> Cc: IETF sigtran
> Subject: Re: FW: [Sigtran] M2PA Last Call Comment
> 
> 
> That does not seem like a good situation. I see the point 
> now. Instead 
> of your suggested text:
> 
>    The proving period MAY be ommitted if this is allowed by the
>    applicable standard (e.g., [Q.2140]); however, the same 
> standard MUST
>    be followed on both sides of the M2PA link.
> 
> would it be better to make a more general statement, in order 
> to avoid 
> this kind of problem that might exist in other procedures? 
> Maybe I could 
>   add to the 2nd paragraph in section 4:
> 
> =====
> Except as modified in this document, M2PA SHOULD follow the
> requirements of the applicable MTP2 specification. These may include
> [Q.703] or [T1.111]. The same standard MUST be followed on 
> both ends of 
> the M2PA link.
> =====
> 
> tomG.
> 
> 
> 
> Brian F. G. Bidulock wrote:
> > Tom,
> > 
> > Q.703 does not give the option to talk to a Q.2140 link.  But it
> > appears that M2PA allows a Q.703-state-machine-based M2PA link to
> > talk to a Q.2140-state-machine-based M2PA link.  That is were the
> > problem ensues.
> > 
> > --brian
> > 
> > Tom George wrote:                                           
>                            (Thu, 17 Jul 2003 17:16:54)
> > 
> >>Brian,
> >>
> >>In the non-IP realm, is it possible for a Q.703 to talk to 
> a Q.2140? 
> >>What would be done in the scenario you described?
> >>
> >>tomG.
> >>
> >>Brian F. G. Bidulock wrote:
> >>
> >>>Hanns Juergen,
> >>>
> >>>Consider that one side follows Q.703 and requires proving while the
> >>>other side follows Q.2140 and foregoes proving.  The following will
> >>>occur:
> >>
>    [...]
> 
> 
> -- 
> * Tom George       PB7-24001 (near B-21)      
> [email-masked]  *
> * 972-519-3168   Intranet:  
> http://www.ssd.usa.alcatel.com/~tgeorge/  *
> * Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, 
> Texas 75075  *
> *   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

---

From: Tom George <[email-masked]>
Date: Fri, 25 Jul 2003 10:28:23 -0500

Hanns,

In the 1st diagram, there is no problem.

In the 2nd diagram, the problem is this: What procedures are the 2 ends 
of the M2PA link following? If one is following a procedure that omits 
proving, and the other is following a procedure that requires proving, 
there is a problem.

You are right that what is happening on the TDM side is not an issue 
here. And I think we agree that both ends of the M2PA link must have 
procedures that are consistent with each other. The text I proposed is 
the best way I can think of to do that.

tomG.

   [...]

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 25 Jul 2003 17:41:02 -0600

Tom,

Sorry, I missed that note.  Your proposed text sounds fine to me.

--brian

Tom George wrote:                                                                      (Fri, 25 Jul 2003 10:28:23)

[snip]
-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/