Subject: [Sigtran] (M2PA) Comments on draft-bidulock-sigtran-m2pa-test-02.ps

From: [email-masked]
Date: Thu, 19 Sep 2002 07:57:49 -0400

Comments on draft-bidulock-sigtran-m2pa-test-02.ps

General Comments

    Thank you for making a M2PA test plan available. Your test cases
    provide very good coverage and are clear and concise. My comments
    and questions are intended to improve my understanding and as
    constructive criticism.

    In my opinion, it would improve clarity to describe M2PA states,
    link status messages, and timers, rather than Q.781 states,
    messages, and timers. In some cases, the names have changed
    to protect the innocent.

    In the following, where I say 'not a M2PA requirement' -- maybe
    it SHOULD be listed in the draft as a requirement, but currently
    it is not (according to my interpretation).

3.1.2 Timer T2

    This is M2PA timer T1.

3.1.3 Timer T3

    Description paragraph appears incorrect. What is the difference
    between this test case and 3.1.4? How does this test case
    apply to M2PA?

3.1.4 Timer T1 & Timer T4 (Normal)

    This involves M2PA timers T3 and T4.

    The description paragraph does not match the M2PA draft in
    that the ALIGNED READY state is exited based on received LSR
    or received DATA, not a received LSPO. The draft does not
    specify that LSPO is an exit event for ALIGNED READY. This
    is a recurring theme in the following PO test cases.

3.1.7
Figure 3.1.7-1 "Alignment" during normal proving

    This figure does not match the test description: LSA should
    be sent after IUT sends LSPN. This test case does not match
    a M2PA requirement (draft does not mention proving restart).

3.1.8.1
Figure 3.1.8-1. Normal alignment with PO set.

    Can IUT issue a LSPO before or during proving?

    Why doesn't this figure show the IUT sending a LSR to PT?

3.1.8.2
Figure 3.1.8-2. Normal alignment with PO set.

    Why doesn't this figure show the PT sending a LSR to IUT?

3.1.9.1
Figure 3.1.9-1. Normal alignment with PO set (Data).

    Isn't this a fault-insertion test case, since DATA is sent
    prior to receiving either LSR or DATA?

    Can IUT issue a LSPO before or during proving?

    Why doesn't this figure show IUT sending a LSR to PT?

    Which state is IUT in when it receives DATA?

3.1.9.2
Figure 3.1.9-2 Normal alignment with PO set (Data).

    Isn't this a fault-insertion test case, since DATA is sent
    prior to receiving either LSR or DATA?

3.1.12.2
Figure 3.1.12-2 "Out of Service" when "Aligned not ready"

    Typo: looks like there is an extra ':start'.

    Why does PT send a READY when it is LPO?

3.1.13
Figure 3.1.13-1 "Alignment" when "Aligned not ready"

    Which state is IUT in when it receives the second ALIGNMENT?

    The transition shown does not match a M2PA requirement. LSA
    received in ALIGNED-READY does not cause transition to OOS.

3.1.16

    This is not M2PA timer T1. M2PA has no equivalent to the timer
    described.

3.1.17

    This test case is incorrect. M2PA proving does not start until
    a LSA is received by IUT. M2PA Timer T1 should time-out in this
    test case.

3.1.19

    This test case is incorrect: PT should send PROVING-NORMAL.

3.1.21

    Figure does not match test case. Both sides should set emergency.

3.1.24

    This test case is incorrect: IUT M2PA timer T1 should timeout due
    to no LSA received. Also, PT should send PROVING-NORMAL unless
    ':set emergency'.

3.1.28

    This test case does not match a M2PA requirement. Receipt of LSA
    during INS does not cause a transition to RETRIEVAL or any other
    state.

3.1.30.2
Figure 3.1.30-2. Deactivation during LPO

    Why is '!rpo' shown occuring after LSO is sent? This suggests that
    the LSO is acted upon prior to the LSPO.

3.1.31.2
Figure 3.1.31-2 Deactivation during RPO

    This test case does not match a M2PA requirement. Upon receiving
    a LSO, regardless of LPO, the link transitions to RETRIEVAL.

3.1.32.2
Figure 3.1.32-2 Deactivation during the proving period

    The diagram does not match the test steps. Why does IUT send a LSO
    after receiving ':start'? If the association was not available when
    ':start' was received, then ':out of service' should have been
    generated after the ':start'.

3.1.33

    This test case does not match a M2PA requirement. Receipt of LSA
    during ALIGNED-READY does not cause a transition to RETRIEVAL or
    any other state.

3.2.2

    M2PA does not require that LSPO be ignored during AIP. The state
    can be recorded and acted upon later.

3.2.3

    M2PA does not require that LSPO be ignored during PROVING. The state
    can be recorded and acted upon later.

    Received LSR during PROVING is not really ignored, though no state
    transition occurs until T4 timeout (PROVING --> INS).

3.2.4

    How does this test case differ from 3.2.3?

3.2.6
Figure 3.2.6-1. Unexpected events while "aligned not ready".

    Why does IUT never issue a LSR? Where in the M2PA draft does it say
    that no LSR is generated if LPO is in effect?

3.3.2

    Why are ACKs received in ALIGNED-READY state?
    Shouldn't IUT move to the INS state after receiving the first ACK
    (User Data)?

3.5.3

    What is meant by 'payload'? Does the payload include the M2PA header?
    Should step three say that a M2PA User Data message having a length
    less than or equal to the size of the M2PA header should not be ACK'd?

3.10.2

    Why does PT send LSB? Figure seems to show ACK after T7 expiry.

Regards,

Jeff

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