Subject: Re: [Sigtran] SUA comments

From: "Tomar, Nitin" <[email-masked]>
Date: Thu, 7 Mar 2002 12:45:21 -0800

John, Brian & Lyndon
 See my comments below.

Thanks
Nitin.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 8:01 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] SUA comments
> 
> 
> Hi Brian,
> 
> I agree with your comments.  However, if anyone feels up to
> starting an implementors guide, please volunteer!
> 
> Thanks,
> John
> 
> > -----Original Message-----
> > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: 07 March, 2002 07:03
> > To: Tomar, Nitin
> > Cc: [email-masked]'; Loughney John (NRC/Helsinki); 
> [email-masked]'
> > Subject: Re: [Sigtran] SUA comments
> > 
> > 
> > Nitin,
> > 
> > Tomar, Nitin wrote:                                        
> > (Wed, 06 Mar 2002 19:10:47)
> > > Hi John,
> > >  Following are few comments on SUA draft 12.
> > > - Nitin.
> > > 
> > > 1. Description of DRST message shall include following :
> > >     When SSN is not included it shall not be passed to 
> > SUA-User at ASP,
> > > instead it shall be used by SUA for
> > >     routing towards SGPs (similar to M3UA routing to a 
> > restricted route).  
> > 
> > SUA is hardly in the position to require this.  An 
> implementation may
> > choose to pass this to the SUA user if it wishes.

 [Nitin]  This is *NOT* an implementation issue, 
  Even MTP3 does not provide RESTRICTED status to its users (SCCP), 
  What possibly the restricted status of a route could be of use to SUA
users.

> > > 
> > > 2. To send DRST message (and DUNA/DAVA) by SG, MTP3 at SG 
> > needs interworking
> > > with SUA, hence a section for
> > >     MTP3 - SUA interworking at the SG is required in the draft.
> > 
> > This is incorrect (particularly for DUNA and DAVA which are already
> > represented in SCCP as the N-PCSTATE primitive).  No MTP3-SUA 
> > interworking
> > is required.  MTP3 at the SG passes these indications as MTP-STATUS,
> > MTP-PAUSE and MTP-RESUME primitives to SCCP which passes the 
> > equivalent
> > N-PCSTATE primitives to the SCCP user.
  [Nitin] For DRST, my comment is same as above,
             For DUNA/DAVA messages - I agree.

> > > 3. Section 3.8.2 Registration Response (REG RSP)
> > >     - The first para has incomplete sentence.
> > >     - Note 1, shall include following statement similar to M3UA:
> > >      "The number of results in a single REG RSP message 
> > MUST be anywhere
> > > from one to the total number of
> > >        Routing Key parameters found in the corresponding 
> > REG REQ message"
> > 
> > This can be caught in the implementor's guide.
     [Nitin] Isn't the SUA is currently under LAST CALL?? so why can not 
                we put this text in draft.
> > > 
> > > 4. Section 3.8.4 Deregistration Response (DEREG RSP)
> > >      - Note 1, shall include following statement
> > >        "The number of results in a single DEREG RSP message 
> > MUST be anywhere
> > > from one to the total number of 
> > >          number of Routing Context parameters found in the 
> > corresponding
> > > DEREG REQ message"
> > 
> > This, too, can be caught in the implementor's guide.
> > 
     [Nitin] Same as above.

> > > 5. Broadcast mode has too many implementation dependent 
> > issues and to fully
> > > understand and implement 
> > >    it one has to refer to a NON IETF approved RFC, I 
> > suggest it shall be
> > > removed from the SUA draft.
> > 
> > Unlikely.
     [Nitin] Many people have tried to understand the usage of broadcast
mode, on
                mailing list one may find lot of stuff explained by Brian
which eventually
                points to his draft and his implementation only
(draft-bidulock-sigtran-corid-00.txt) and the
                general feeling I got from M3UA interoperability is that
                broadcast mode can not be implemented without co-relation id
draft. 

> > > 
> > > 6. In section 4.4.1 Registration,
> > > 
> > > I suggest adding following paragraph:
> > > If an SGP determines that a received Routing Key is already 
> > registered by
> > > the ASP, the SGP shall return already allocated RC for the 
> > corresponding AS
> > > to the ASP, and if AS is in ACTIVE state then SGP shall 
> > mark its state to
> > > INACTIVE.
> > 
> > This is unnecessary.  If the ASP loses its registration state 
> > it should
> > start again with ASPUP.
     [Nitin] This is necessary, as during the M3UA interopt, consensus
                was same as what I have stated above, consider the following
                text of M3UA draft -
                                
               If an ASP Up message is received and internally the remote
ASP is in 
               the ASP-ACTIVE state, an ASP Up Ack message is returned, as
well as an 
               Error message ("Unexpected Message), and the remote ASP state
is 
               changed to ASP-INACTIVE in all relevant Application Servers.

   IMO the above scenario explained in M3UA draft is similar to getting
   a duplicate registration request for a same RK from ASP even if AS is in
Active state. 

> > --brian
> > 
> > > 
> > > 
> > > _______________________________________________
> > > 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: Thu, 7 Mar 2002 15:53:52 -0600

Nitin,

Tomar, Nitin wrote:                                        (Thu, 07 Mar 2002 12:45:21)
>   What possibly the restricted status of a route could be of use to SUA

How an implementation interacts with its users *is* an
implementation matter.  SUA does not dictate to an
implementation how it interacts with its users.  It does
provide support for SCCP Primitives, but does not mandate
the interface between an SUA implementation and its users.

Not even the SS7 standards bodies mandate the interface
between SCCP and SCCP-Users.  It provides description of
an interface (the primitive interface), but this is
descriptive and not requirements of the protocol either.

>              For DUNA/DAVA messages - I agree.

Same as above.  SUA cannot mandate an implementation's interface
to its users.

>                 we put this text in draft.

I believe it has completed ISEG last call an is in the hands
of the RFC editor.

> > > This, too, can be caught in the implementor's guide.

Same as above.

>                 broadcast mode can not be implemented without co-relation id

This is far from the case.  Broadcast mode has been included in M2UA for
close to a year now, and has been included in M3UA and SUA for over
six months.  Aside from your recent statements, I have seen noone asking
for it to be removed, even though the mode has been dicussed in great
detail in the working group in the past.

Nevertheless, if it is not used by two or more implementors between
Proposed Standard and Draft Standard the feature will be dropped.  Until
such gn eventuality, there is no need to remove it from the draft after
the WG spent so much time getting it in there in the first place.

If you don't like it, don't implement it.  Please stop trying to keep
others from implementing it.

>                 was same as what I have stated above, consider the following

The interop does not represent the concensus of the working group and is
not part of the IETF process.  This was discussed in detail in the WG
and the RFC represents the result of the IETF process.

>                                 
>                If an ASP Up message is received and internally the remote ASP is in 
>                the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an 
>                Error message ("Unexpected Message), and the remote ASP state is 

No, it is not similar.  When an SGP receives a duplicate REG REQ for the
same routing key, it is fully within its rights to assume that this is
a different AS than the one which previousy registered and returning an
error is appropriate.  If an ASP that does not know its registration state
has some other serious problems (it cannot know the RC from the registration
either) and should reset by sending ASPUP.

Nevertheless, a specific SG/SGP implementation that has additional information
about the registration state of ASPs by other means (provisioning,
configuration) is equally well permitted to return whatever error message
it sees fit, or even perform the approach that you describe.  It is not the
place of the RFC to force an implementation to act in a particular way here.
All of the protocol messages and error conditions already exists in the
protocol to permit the ASP and SGP to work this situation out in an
interoperable fashion.

No modifications are needed to the RFC.

--brian

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