Subject: Re: [Sigtran] M3UA outstanding issues

From: [email-masked]
Date: Fri, 5 Apr 2002 13:10:13 -0500

Ken,

Please see my replies inline.

Barry Nagelberg

Ken Morneault <[email-masked]>
Sent by: [email-masked]
04/05/02 10:41 AM

        To:     [email-masked]
        cc: 
        Subject:        [Sigtran] M3UA outstanding issues
------------------------------------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.

[BN] I agree with Brian. The purpose of broadcast mode is never explicitly 
explained. What is especially confusing is that there seems to be an 
implicit connection between broadcast mode and "sufficient resources" - 
see Section 4.3.4.3 (ASP Active Procedures). I would have assumed that the concept of "sufficient resources" would be linked only to loadshare mode. The the 
purpose of Correlation Id is also very unclear - it is linked to the 
concept of "traffic flow", which is never defined. See my issue 7 below.

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?

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?

_____________________________________________________________
[BN] My favorite open issues:
7) Traffic flow - This term is used in several places throughout the draft 
but is never defined.
8) Error reporing - Still very weak and non-robust. Just as the REG RSP 
message has a result field (Registration Result), so too should the ASPUP 
ACK and ASPAC ACK messages have a result field.

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 8 Apr 2002 16:11:19 -0700

Hi Folks,

My view is that the implementor's guide is primarily for corrections
and clarifications to the original M3UA.  If we need a new message
or procedure that is best put in a separate draft.

This will make the documentation a bit more complex, as has been
pointed out.  However, this is pretty standard procedure for IETF,
I think, as the original RFC is never changed, it can only be
supplemented or completely replaced.  I asked, in fact, on the
SCTP checksum, which seemed to me to be a case where having
some kind of note or pointer added to RFC2960 would make a lot
of sense, however the policy is that the RFC, once published,
is never changed.  You have to go to the RFC list to find out
what documents may have supplemented or obsoleted the original.

Cheers,

Lyndon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, April 08, 2002 4:02 PM
To: [email-masked]
Cc: [email-masked]; Ong, Lyndon
Subject: Re: [Sigtran] M3UA outstanding issues

Barry,

Valid questions.  Lyndon?

--brian

[email-masked] wrote:                (Mon, 08 Apr 2002
17:29:23)
> In one "extension draft", or in multiple drafts such as 
> draft-bidulock-sigtran-corid-00.txt, 
> draft-bidulock-sigtran-loadgrp-00.txt, etc.
> 
> If it is in one extension draft, then fine. I understand that we can't 
> keep modifying the M3UA draft endlessly AND get an RFC. But it is 
> unacceptable that basic concepts used in the M3UA RFC, such as "traffic 
> flow", can be defined in any one of multiple "draft-bidulocks" or 
> "draft-<insert a person's name here>".
> 
> Who is going to compile the list of all the extensions through which the 
> user must search? And even if such a list exists, why torture the user by 
> making him/her actually perform this search? Basic concepts must be 
> defined in a single extension, which should be
draft-ietf-sigtran-m3ua-implementors-guide-00.doc.
> 
> Barry Nagelberg
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]>
> 04/08/02 05:18 PM
> Please respond to bidulock
> 
>  
>         To:     [email-masked]
>         cc:     [email-masked]
>         Subject:        Re: [Sigtran] M3UA outstanding issues
> 
> 
> 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)
> > 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]>
> > 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]
> > > 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
> > > 
> > > [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.
> > > 
> > > allowing Network Indicator (i.e. change Service Indicator field to SIO

> > or
> > > [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.
> > > 

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

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