Subject: Re: [Sigtran] M2PA draft comments and questions.

From: [email-masked]
Date: Wed, 12 Feb 2003 08:33:17 -0500

Hello Guys,

Another round... comments are embedded.

Regards,

Jeff

On 02/11/2003 10:33:11 PM sigtran-admin wrote:

>John,
>John Li
>wrote:

>(Tue, 11 Feb 2003 21:41:07)
>>
>> Hi, Jeff,
>> Thanks for the responses. Further comments are inline.
>> Thanks,
>> John
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, February 11, 2003 1:24 PM
>> To: John Li
>> Cc: [email-masked]
>> Subject: Re: [Sigtran] M2PA draft comments and questions.
>>
>>
>>
>> Hello John,
>>
>> Since no one else is responding, I'll answer.
>>
>> My responses are embedded below.
>>
>> Regards,
>>
>> Jeff
>>
>> On 02/11/2003 10:09:47 AM sigtran-admin wrote:
>>
>> >All,
>> >I sent the following comments and questions to the group a while ago,
and
>> have
>> >not got responses yet. here goes again.
>> >thanks.
>> >John
>> >
>> >
>> >1.   In section 1.5: the following statement is somewhat confusing.
>> >"The SG is an IPSP equipped with both traditional SS7 and IP
>> >network connections. In effect, the Signaling Gateway acts as a
>> >Signal Transfer Point (STP)"
>> >
>> >Perhaps we can say "The SG interconnects SS7 and IP networks by
>> >converting signaling traffic" or just refer to the definition in
>> >section 1.2
>>
>> I am not sure what defect this removes, and so I have no comment on
this.
>>
>> >
>> >
>> >2.   Section 2.1.5 Message length
>> >Should we specify the valid value range of the length?
>> >
>>
>> No. Min/Max message length is dependent on message type,
>> and in the case of user data is governed by MTP3.
>>
>> [John] the max payload MTP2 can carry is 272 octets. So by leaving that
>> unspecified, it would be fine if M2PA used in a pure IP environment, but
>> would have issues when used in a SG, who will be doing the segmentation
and
>> reassembling when receiving oversize(>272) messages from peer M2PA
before it
>> can be passed to the ss7 network?
>
>MTP3b does not limit to 272 octets.  Neither does Q.703 Annex A.
>
>This is a network restriction understood by MTP3.  M2PA imposes no
>restriction on message size.
>
>>
>> >3.   Section 2.3.1 User Data
>> >
>> >statement "M2PA does not add padding to the MTP3 message.".
>> >I think we should make it a requirement: "M2PA should not add padding
>> >to the MTP3 message."
>> >
>>
>> Sounds good to me.
>
>It is necessary to say MUST rather than SHOULD.
>
>>
>> >
>> >4.   In section 4.1.3 Link alignment
>> >
>> >perhaps we can specify the recommended practice for choosing
>> >emergency proving vs. normal proving during alignment procedure.
>> >
>>
>> This is governed by MTP3 procedures and is outside the scope
>> of the M2PA draft.
>>
>> [John] I thought about the scope issue as well. But since the draft
covers
>> MTP3 changeover in 2.4.6, by the same token, it would be very useful to
add
>> a paragraph to explain the two different alignment procedures in section
>> 2.4: Procedures to Support the MTP3/MTP2 Interface.
>
>
>Changeover is discussed because the chnageover message contains
>the MTP2 sequence number.  XCO/XCA need to be used due to M2PA's
>larger sequence number.
>
>Emergency vs. Normal proving is adequately addressed by MTP3 which
>is cited as a reference.
>
>>
>> >
>> >5.   Section 4.1.8:
>> >"If a Link Status Alignment message with an unsupported
>> >received by the newer version, the receiving end's M2PA
>> >SHALL NOT complete the alignment procedure."
>> >
>> >can we clearly define the behavior of not completing the alignment
>> >procedure?
>>
>> I believe that you are suggesting that the text be reworded to state
>> the following:
>>
>> "If a Link Status Alignment message with an unsupported version
>> is received by the newer version, the receiving end's M2PA
>> SHOULD fail the link."
>>
>> I think this was already understood, but the change improves clarity.
>>
>> [John] Further, I am thinking in this case, what is the procedure to
prevent
>> further alignment when the M2PA knows the incompatible versions: for
>> example, should M2PA notify its upper user about the incompatible so
that
>> the upper layer will not initiate alignment again. what is the status to
the
>> M2PA user to indicate it should not try to re-align if so, etc.
>
>Management procedures are implementation dependent.

(Jeff)
I agree that requesting that the upper layer stop trying to align the link
is
outside the scope of the M2PA draft. There is no MTP3 primitive for this.
There is nothing preventing the implementor from maintaining and
reporting 'M2PA version error' measurements.

The initial question was: "What is the definition of 'SHALL NOT complete
the alignment procedure'".

The draft currently implies that the unsupported LSA is simply ignored.
This means that alignment will ultimately fail due to T2 expiry by the
receiver of the unsupported LSA. This also means that the sender is
likely to advance to PROVING. I see no problem with this.

So the text at 4.1.8 should be clarified:

OLD TEXT
In case a newer version of M2PA is incompatible with an older version,
the newer version SHOULD recognize this and prevent the alignment of
the link. If a Link Status Alignment message with an unsupported
version is received by the newer version, the receiving end's M2PA
SHALL NOT complete the alignment procedure.

NEW TEXT
In case a newer version of M2PA is incompatible with an older version,
the newer version SHOULD recognize this and prevent the alignment of
the link. If a Link Status Alignment message with an unsupported
version is received by the newer version, the receiving end's M2PA
MUST discard the message.

>
>--brian
>
>--
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>_______________________________________________
>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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 08:21:03 -0700

Jeff,

[email-masked] wrote:                                             (Wed, 12 Feb 2003 08:33:17)
> likely to advance to PROVING. I see no problem with this.

The sender should not necessarily advance to proving, unless it likes
the verion of a received ALIGNMENT or PROVING message.

> MUST discard the message.

I would say that if it receives any message with an unsupported version
it SHOULD discard the message and not act upon it.

(SHOULD not MUST, because "unsupported" is not clearly defined.)

--brian

---

From: Tom George <[email-masked]>
Date: Thu, 20 Feb 2003 15:33:10 -0600

Regarding item 5 in John's list:

IMHO the newer version of M2PA SHOULD send a LS OOS in reply to the
unsupported LSA, instead of just discarding it. That would be more
effective in stopping the alignment procedure. 

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 USA, Inc. 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Feb 2003 14:46:29 -0700

Tom,

How can an implementation not support LSA?

--brian

Tom George wrote:                                                                      (Thu, 20 Feb 2003 15:33:10)

---

From: Tom George <[email-masked]>
Date: Thu, 20 Feb 2003 15:55:41 -0600

That would be tragic. 8-) I meant an LSA with an unsupported version
number. 

I put my updated wording in the other message I just sent out.

tomG.