Subject: [Sigtran] comments for updated M3UA test document

From: Tolga Asveren <[email-masked]>
Date: Mon, 28 Oct 2002 09:05:26 -0500

Hi Sandeep,

*"Configuration G: This simple configuration is used for all the procedures
of tests concerning single IPSP_IPSP configuration. The Routing Key for this
configuration is DPC+OPC ." 
For IPSP DPC+OPC is mandatory (like DPC is mandatory for ASP/SGP case) but
it might contain other elements for example one can have a RK DPC+OPC+SIO.
So, IMO, it is not necessary to limit the RK for IPSP case to just DPC+OPC.

*
              SGP                             ASP1
               |                               |
               |<-------------ASP Up-----------|
               |-----------ASP Up Ack--------->|
               |                               |
               |<------- ASP Active(RCn)-------|  RC: Routing Context
               |-----ASP Active Ack (RCn)----->|      (optional)
               |                               |
               |-----NTFY(AS-ACTIVE)(RCn)----->|
               |                               |

There is also NTFY(AS-INACTIVE) after ASP UP/ACK exchange. In general in the
document, this NTFY is ignored.

*"- Optional test for Implementations supporting ASP ID (Dynamic
provisioning of IP Address and/or SCTP port) in messages. Sequence · The
Transport Address statically configured at SGP for the ASP is T1 and the
SCTP association is established with Transport Address T2.The ASP is
statically configured to have ASP ID'I'. · Send ASPUP from ASP (at Transport
Address T2) to SGP with ASP ID 'I'. · SGP updates the Transport Address for
ASP (with ASP ID 'I') to T2 which was in ASP-Down state up till now. · ASPUP
was successfully processed at the ASP and the state of ASP has changed to
ASP-Inactive. ASPUP-Ack and NTFY messages have been sent to ASP."
IMO, a test case, where no transport address for ASP1 is preconfigured is
more appropriate. For the above case, one could argue, what the correct
behaviour is, to accept the association request or not. 

*Test 3.1.5.
"DATA should be loadshared among SG1 and SG2 and hence among SGP1 and SGP2
i.e. One DATA message reaches SGP1 and the other should reach SGP2."
IMO, a configuration, where each SG consists of multiple SGPs, would be more
interesting.

*Test 3.2.2. has some typos: MTP3 PAUSE indication causes DAVA and MTP3
RESUME indication causes DUNA. 

*Test 3.2.4
· The NIF sends MTP3-STATUS indication to M3UA at SGP2. · The SGP2 sends a
DRST message to the ASP. 
I don't know what this indication should be named (because MTP3 informs user
parts with MTP-RESUME after receiving DRST, if the corresponding destination
was unreachable before), but I think MTP-STAUS indication is a misleading
name.

* In general it could be mentioned that audit mechanisms are optional.

---

From: [email-masked]
Date: Wed, 30 Oct 2002 16:14:46 +0530

Hi Tolga,

Please see the replies inline.

Best Regards,
-Sandeep

Tolga Asveren <[email-masked]> on 10/28/2002 07:35:26 PM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  [Sigtran] comments for updated M3UA test document

Hi Sandeep,

Sandeep >>  Is it OK to say that IPSP tests can be executed for the following RK
combinations.
    DPC+SIO+OPC
    DPC+OPC
    DPC+CIC+OPC+SIO
    DPC+CIC+OPC

*
              SGP                             ASP1
               |                               |

Sandeep >> This diagram was taken directly from RFC. We would updated the first
test case to shown this explicitly. In other test cases since the purpose of
test cases is not to test this feature, we would assume the same to be implied.
BTW, do you think the same should be updated in RFC also.

*"- Optional test for Implementations supporting ASP ID (Dynamic
provisioning of IP Address and/or SCTP port) in messages. Sequence 

· The

IMO, a test case, where no transport address for ASP1 is preconfigured is more
appropriate.
Sandeep >> We would update this test case to include sequence to test the above
scenario.

For the above case, one could argue, what the correct behaviour is, to accept
the association request or not.
Sandeep >> Implementations supporting dynamic configuration/mapping of Peer
Transport addresses to ASPs, would allow SCTP associations to be accepted from
any un-configured Peer Transport Addresses. So in above case IMO the association
request should be accepted.

*Test 3.1.5.
"DATA should be loadshared among SG1 and SG2 and hence among SGP1 and SGP2 i.e.
One DATA message reaches SGP1 and the other should reach SGP2." IMO, a
configuration, where each SG consists of multiple SGPs, would be more
interesting.
Sandeep >> Actually Configuration E tests the scenario where there are multiple
SGPs in a single SG and configuration tests the scenario where there are
multiple SGs present. Please let me know if you think that a new configuration
needs to be added that combines configuration E and F.

*Test 3.2.2. has some typos: MTP3 PAUSE indication causes DAVA and MTP3 RESUME
indication causes DUNA.
Sandeep >> We would correct this.

*Test 3.2.4

I don't know what this indication should be named (because MTP3 informs user
parts with MTP-RESUME after receiving DRST, if the corresponding destination
was unreachable before), but I think MTP-STAUS indication is a misleading
name.
Sandeep >> We would correct this.

* In general it could be mentioned that audit mechanisms are optional.
Sandeep >> We would add this as note after Test case 3.2.1 that deals with point
code auditing.

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 30 Oct 2002 08:39:35 -0500

Hi Sandeep,
> BTW, do you think the same should be updated in RFC also.
[TOLGA] It could be nice that this was already updated in M3UA RFC but the
way choosen to fix this was to add the sentence "NOTE: Not all the Notify
messages that are appropriate per the Notify procedures are shown in these
examples." at the beginning of 5.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran