Subject: Re: [Sigtran] M3UA outstanding issues

From: [email-masked]
Date: Mon, 8 Apr 2002 16:00:08 -0400

But the concept of traffic flow is _used_ in the M3UA RFC-to-be. If I 
correctly understand our current working group strategy, we are putting 
all omissions and defects in 
draft-ietf-sigtran-m3ua-implementors-guide-00.doc. Therefore the concept 
of traffic flow should be added there as well.

I hope that we are not going to reach a situation where a user of the M3UA 
RFC must search through multiple "companion" drafts and RFCs for 
definitions that are missing from the M3UA RFC.

Barry Nagelberg

"Brian F. G. Bidulock" <[email-masked]>
Sent by: [email-masked]
04/08/02 03:59 PM
Please respond to bidulock

        To:     "Vats, Umesh" <[email-masked]>
        cc:     "'Ken Morneault'" <[email-masked]>, [email-masked]
        Subject:        Re: [Sigtran] M3UA outstanding issues

Umesh,

The concept of traffic flow is explained in
draft-bidulock-sigtran-corid-00.txt

--brian

Vats, Umesh wrote:                           (Mon, 08 Apr 2002 09:29:48)
> Please see my comments below
> 
> Umesh
> 
> -----Original Message-----
> From: Ken Morneault [mailto:[email-masked]]
> Sent: Friday, April 05, 2002 7:41 AM
> To: [email-masked]
> Subject: [Sigtran] M3UA outstanding issues
> 
> 
> 
> 
> All:
> 
> The following are open issues that have not been fully discussed
> on the list.  Please provide feedback so that we can bring them
> to conclusion.
> 
> Also, if you favorite open issue has been forgotten, please resend
> it to the list.
> 
> Regards,
> 
> Ken
> 
> ------------------------------------open
> issues---------------------------------------
> 
> 
> 1)  use of broadcast mode not fully specified (use of correlation id 
> not fully specified either)
> 
> This concern was addressed by Brian on the list.  If there is still 
> discontent, could some specific complaints be listed or additional 
> text proposed.
> [UMESH] Broadcast mode assumes the use of correlation Id. But this
>         linkage is never explained. Also, how exactly to use
>         correlation id is not specified.
>         The concept of traffic flows is also not explained in the draft.
>         Details regarding this are missing in the implementor's guide.
> 
> 2)  REG msg only has Service Indicator.  There is interest in also 
> allowing Network Indicator (i.e. change Service Indicator field to SIO 
or
> add NI parameter to message).
> 
> Comment on the list that NA is sufficient.  Is there a need for NI in 
> REG message?
> 
> 3)  There was a long thread about the use of ASP ID.  Do some folks
> still feel additional explanatory text is required or can we close this
> issue?
> [UMESH] The scope of uniqueness of ASP Ids  is not explained. As per the 

>         discussion, it came out the ASP Id is unique per ASP/SGP
>         pair. This can be added in the implementor's guide. 
>         In the discussion, it came out that ASP Id is not always
>         optional. In some cases, it is a MUST parameter (when dynamic
>         port allocation is at ASPs is used). This also needs to be
>         specified. The possible uses of ASP Ids at the ASPs receiving
>         them can be mentioned.
> 
> 4) Handling traffic flow (i.e. destination) based Changeback (reference
> ITU Q.704  Clause 6.2.1 b (i))
> 
> 5) For SSNM with multiple Affected Point Code fields and with multiple 
> RC fields, it should be described, how to correlate RC values to the
> Affected 
> Point Codes.
> 
> 6)  Discrepancy between implementations regarding uniqueness
> of Routing Context
> 
> Scenario  ASP sends REG Routing Key request to each SGP 
> per M3UA.
> 
>    Issue 1:  Can each SGP respond with different Routing Context
>                  to REG request for the same Routing Key.
> 
>    Issue 2:  Why does ASP need to send REG RK to each
>                  SGP when AS/Routing Key is across SG?
> 
> 
> _______________________________________________
> 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/

_______________________________________________
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: Mon, 8 Apr 2002 16:18:40 -0500

Barry,

We agreed that for the sake of releasing an RFC that these issues
would be address in "extension draft".

--brian

[email-masked] wrote: (Mon, 08 Apr 2002 16:00:08)

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