Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m3ua-implementors-guide-02.txt

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Jan 2003 03:36:43 -0700

Resend...

SIGTRAN,

Ken Morneault wrote:                                                                   (Fri, 20 Dec 2002 13:22:50)
> 
> 
> Brian,
> 
> Pls see my feedback below.   I removed the items that already
> had consensus or were minor edits.  For the rest, we need more
> feedback on the list before progressing.
> 
> Regards,
> 
> Ken
> 
> At 02:51 PM 12/19/2002 -0700, Brian F. G. Bidulock wrote:
> >Ken,
> >
> >Please see additional comments below...
> >
> >Ken Morneault wrote:                              (Thu, 19 Dec 2002 15:14:57)
> >> 
> >> 
> >> Brian,
> >> 
> >> Pls see comments below.
> >> 
> >> Ken / Javier
> >> 
> >> At 03:43 AM 12/18/2002 -0700, Brian F. G. Bidulock wrote:
> >> >Some comments on this version of the IG:
> >> >
> >> >Section 3.2
> >> >
> >> >  This section is unnecessary.  It was always intended that the M3UA entity
> >> >  sending the ERR message include the offending message in the Diagnostic.
> >> >  This appears in RFC 3332 section 3.8.1:
> >> >
> >> >   Diagnostic Information: variable length
> >> >
> >> >      When included, the optional Diagnostic information can be any
> >> >      information germane to the error condition, to assist in
> >> >      identification of the error condition. The Diagnostic information
> >> >      SHOULD contain the offending message.
> >> >
> >> >  I don't see any reason to say MUST for REG REQ.  The SHOULD is sufficient
> >> >  to cover all cases.  It was clear from discussions that if the Diagnostic
> >> >  information does not contain the offending message, that correlation of
> >> >  Error messages with the messages that cause them will be impossible in
> >> >  many circumstances.
> >> 
> >> 
> >> This ambiguity is exactly what folks wanted to avoid in the case of REG REQ.  Having
> >> "MUST instead of "SHOULD" does provide a benefit in this case.
> >
> >And what is that benefit?  A requirement to support a Error procedure at
> >the SG for an optional feature of the protocol?  I don't see a
> >interoperability need for an SG to support this procedure if the SG knows
> >that it will never connect to an ASP which dynamic registers.  Dynamic
> >registration is, after all, OPTIONAL.
> >
> >Change "MUST" to "SHOULD".
> 
> Although the feature is optional, the SG must return an error.  The
> change to the text just makes it mandatory for the ASP and SG
> to always include the Diagnostic information for Msg Class/Type
> errors so that the other side can correlate.  

So why should correlation be mandatory for this case and not all others?
There are many other cases where correlation causes problems.  I think it
is time to revisit the SHOULD or the MUST.  As I recall you were the one
advocating SHOULD in the first place for offending messages in Diagnostic
and those that reported correlation problems were asking for MUST.  Can
you continue to defend SHOULD for other cases?  If you are making a unilateral
decision to say MUST for the one error, also remove "germane" and change
"SHOULD" to "MUST" under "Diagnostic Information" above.

> 
> 
> 
> >> 
> >> 
> >> 
> >> 
> >> >Section 3.4
> >> >
> >> >  This section is against the concensus in the RFC.  The concensus was
> >> >  that if an SGP suffers a partial failure, it should send ASP Inactive
> >> >  Ack for the affected AS, and that if it should suffer a complete
> >> >  failure, it should send ASP Down Ack.
> >> 
> >> Most of this text came from some of your proposed text in a long thread 
> >> (titled "NIF not available") after the M3UA draft was frozen.  I think the only 
> >> conflict with your proposal is sending DUNA(s) in the case of the partial
> >> failure case.  
> >
> >It was discussed long before that.  That is why there is the wording
> >in the RFC concerning the response to ASP Down Ack and ASP Inactive Ack
> >in the case that no ASP Down or ASP Inactive has been sent: it is because
> >we discussed partial and complete failure in the WG perviously (at the
> >same time as we changed SNMM back from being per-SGP to being per-SG,
> >shortly after the s/SG/SGP/g fiassco) which was back at about Draft7 or 8.
> >
> >At that time we agreed that SSNM was per-SG (e.g. DRST cannot be used to
> >redirect traffic between SGP in the same SG) and that ASPSM/ASPTM was
> >per-SGP.  We also agreed at that time that DUNA was inappropriate in
> >response to SGP failures (because they are per-SG, and intended to
> >reflect SS7 network management and not ASP management) and the ASP
> >Inactive Ack and ASP Down Ack were the appropriate response to partial
> >and complete failures of the SGP (because they are per-SGP and intended
> >to reflect ASP management, not SS7 network management).
> >
> >I can dig up the threads if you'd like, but the matter was settled
> >a long time ago.  It just resurfaced after the draft was frozen.
> 
> I know it was discussed before that.  However, that thread was the final
> discussion and the one from which the test changes were pulled.  

Sending DUNA for partial failure does not appear in that discussion:
what that your own invention?  Strike it.  It was never discussed.

On the other hand, ASP Down Ack was discussed in that thread.

Also, DUNA(*) was mentioned as appropriate, but so was ASP Inactive Ack
and ASP Down Ack.  I don't know how you could possible state DUNA(*)
as a MUST when there are other options for the SG designer to respond
to what is clearly an event which is outside the scope of the document:
an event of the "implementation-depdendent NIF."

Strike the "MUSTs" and put "MAY," or "MAY, for example," because it is an
implemetation issue and not a protocol issue.  The results from sending
any of these messages is clearly stated in the protocol.  When to send
them is an implementation matter.

> 
> 
> >Now, the IG attempts to again use SSNM where ASPSM/ASPTM is proscribed.
> >
> >
> >> 
> >> >  DUNA(*) is completely incorrect, particularly because the ASP is
> >> >  permitted to interpret DUNA(*) from one SGP to mean DUNA(*) from
> >> >  all SGPs in an SG.  SNMM are not per-SGP messages and were kept
> >> >  as indicating routing at SG scope.  Section 3.4 is in conflict with
> >> >  this.
> >
> >I should have said DUNA not DUNA(*) above, but,
> >
> >> 
> >> DUNA(*) is only proposed in the case in which the SG (all SGPs) have
> >> lost contact with the NIF (or SS7 network).
> >
> >DUNA(*) is inappropriate because the SG has not lost accessibility to these
> >destinations.  When the NIF recovers. there is no procedure to inform
> >the AS that these destinations are indeed available.  ASP Down Ack is
> >appropriate because it informs all AS at all ASPs that they have lost
> >connectivity to the NIF from a given SGP.  When the NIF recovers and
> >the ASP performs its normal startup DAUD procedure (if required).
> >With DUNA(*) the ASP is given no indication when the NIF recovers and
> >does not know to perform DAUD.
> >
> >MTP/MTP-User interfaces use means other than MTP-PAUSE to indicate
> >whether the MTP-User is "connected" to MTP or not (bind, attach),
> >and when that connection fails (error return, exception).  MTP-PAUSE is
> >reserved for MTP to inform its user that a remote destination is
> >inaccessible to MTP, not when the local MTP is inaccessible to the
> >MTP-User.
> >
> >DUNA (without the *) is inappropriate for the reasons cited.  It falsely
> >indicates to the AS that the destination is inaccessible to the SG rather
> >than the fact that a single SGP is suffering a partial failure.  In the
> >world of MTP/MTP-User interfaces there is no "partial failure", it is
> >an all or nothing deal: either the MTP can provide service or it cannot.
> >When an SGP suffers a partial failure, it should send ASP Inactive Ack
> >so that the ASP knows to route traffic to alternate SGPs.
> >
> >So, again, please change DUNA(*) to ASP Down Ack and DUNA to ASP Inactive
> >Ack in this passage.  There should be no mention of SSNM being sent in
> >regard to SGP failures.
> 
> While I'm not necessarily opposed to making some mods to this text, I
> still think we need more feedback before we start making changes.

Here's feedback: its broken; fix it.

> 
> >> 
> >> >Section 3.9
> >> >
> >> >  SCON(0) was always intended to be optional.  Strike the requirement
> >> >  to send SCON(0) (i.e. strike Section 3.9).  Again this was discussed
> >> >  at length on the list we arrived again at SCON(0) being optional.
> >> >  Strike section 3.9.
> >> 
> >> I think you are referring to the thread "Another Congestion/SCON Question".
> >> This outcome of this thread has not been worked into the IG yet.
> >
> >You can work it into the IG by striking section 3.9.
> 
> I believe there is value in Section 3.9 as there had been comments about what
> the SG should send when audited.  Section 3.9 provides a clear description
> which was lacking in the RFC.

The description is not clear, because as it stands it is incorrect.

> 
> >> 
> >> >Section 3.10
> >> >
> >> >  This section is unnecesary.  The RFC clearly states in Section 4.3.4.4:
> >> >
> >> >    "The SGP MUST send an ASP Inactive Ack message in response to a
> >> >     received ASP Inactive message from the ASP and the ASP is already
> >> >     marked as ASP-INACTIVE at the SGP."
> >> >
> >> >  Deregistration does not change the state of the ASP in the AS.  In
> >> >  particular it does not move it to the ASP-DOWN state.  The only actions
> >> >  moving an ASP to the ASP-DOWN state are the successfuly completion of
> >> >  the ASP Down Procedure or the loss of the SCTP association.  Therefore,
> >> >  in the example, according to section 4.3.4.4 the SGP MUST send ASPIA Ack
> >> >  regardless of the fact that the ASP has deregistered for the routing key.
> >> >
> >> >  Then new text for Section 4.5.3 is in conflict with the MUST in
> >> >  section 4.3.4.4, becuase it requires an Error instead of an ASP Inactive
> >> >  Ack in the same situation (ASP in the ASP-INACTIVE state).
> >> >
> >> >  Strike section 3.10.
> >> 
> >> I don't see how it conflicts with Section 4.3.4.4.  In the case of a static
> >> Routing Key, a SG would not return ASP Inactive Ack if the Routing
> >> Context was invalid.  Instead, it would return an error.  The new text
> >> clarifies the same for the dynamically configured Routing Key.
> >
> >The Routing Context is valid in the example case that the solution
> >is claiming to address.
> >
> >Also, just because the RK is not registered does not mean that the
> >Routing Context is invalid.  The Routing Context being an index
> >into the routing table, means that it can be valid as long as there
> >is a Routing Key in the table.  It is at the SG's discretion upon the
> >last ASP deregistering for a key whether to leave it in the routing
> >table or to strike it.  Therefore, where the IG says:
> >
> >       -  If the RK is not registered, or the RC information is not valid,
> >          the peer must respond with an ERROR message with Error Code =
> >          "Invalid Routing Context".
> >
> >is incorect, because the RK being not registered does not necessarily
> >mean that the Routing Context is invalid.  
> 
> 
> While I agree that RK may exist in the database, the ASP has deregistered.
> Therefore, the RK would no longer be associated with that ASP (of course,
> it may be associated with other ASPs).

Are you saying that the ASP is moved to the ASP-DOWN state?  This is
incorrect (and the RFC does not agree with you).  ASP Down is required to move
the ASP to the ASP-DOWN state.  Therefore, the ASP is in the ASP-INACTIVE
state for the AS and the text is clear in the RFC that the SGP "MUST" send
ASP Inactive Ack.

If you don't want that to be the case, you need to change the state diagrams,
and the registration procedures, and a lot of things in a lot of places.
Where do you get the mandate to make all these changes to the registration
procedure?

You should get more feedback before placing such things in the IG.

Strike section 3.10.

> 
> >See RFC section 4.4.2 which
> >states:
> >
> >     The deregistration procedure does not necessarily imply the deletion
> >     of Routing Key and Application Server configuration data at the SG.
> >     Other ASPs may continue to be associated with the Application Server,
> >     in which case the Routing Key data SHOULD NOT be deleted.  If a
> >     Deregistration results in no more ASPs in an Application Server, an
> >     SG MAY delete the Routing Key data.
> >
> >The remainder of the IG section is either wrong, already stated in
> >the RFC or contradictatory:
> >
> >For annother example of wrong:
> >
> >  the IG says
> >
> >    ---------
> >    New text: (Section 4.5.3)
> >    ---------
> >
> >  The section is 4.3.4.4.
> >
> >
> >For example of contradictory:
> >
> >  the IG says:
> >
> >       - If the corresponding RK is registered (statically or
> >         dynamically), the peer should respond with an ASP Inactive Ack
> >         message.
> 
> Right, but it is no longer registered so this statement doesn't apply.
             ^^

"It," being the RK in the statement above, can continue to be registered.

> 
> >  the RFC (later in section 4.3.4.4) says:
> >
> >     The SGP MUST send an ASP Inactive Ack message in response to a
> >     received ASP Inactive message from the ASP and the ASP is already
> >     marked as ASP-INACTIVE at the SGP.
> 
> Granted, but the SGP would first validate the ASP Inactive message before
> replying.  If it found the RC in the message did not match any RKs the
> ASP was registered to, it would return an Error.

Nowhere does it say in the RFC that the SGP screens messages for RC values
that are only registered to ASPs.

There is also nothing in the RFC requiring that the SGP "forget" its static
configuration information just because an ASP deregisters.  Otherwise, the
static and dynamic approaches could not co-exist.  You must leave room for
the case where an SGP supports both static and dynamic configuration to ASPs
because it is permitted.  So the SGP in fact is permitted not to remove
Routing Keys and is also permitted to treat and ASP as though it is statically
registered after it deregisters.  This is why the section is contradictory,
it presupposes to tell the SG how to treat the ASP when the option is no
longer in effect.

> 
> 
> >For an example of duplication:
> >
> >  the IG says:
> >
> >       -  If the RK is not registered, or the RC information is not valid,
> >          the peer must respond with an ERROR message with Error Code =
> >          "Invalid Routing Context".
> >
> >  the RFC (later in section 4.3.4.4) says:
> >
> >                    ... The SGP or IPSP sends an Error message ("Invalid
> >     Routing Context") message for each invalid or unconfigured Routing
> >     Context value in a received ASP Inactive message.
> >
> >And that covers all the proposed changes for the section, so please
> >strike the section.
> 
> One could argue that this text in the RFC is sufficient, but there was
> enough confusion for people to request some clarifying text.

Repeating the same statements with errors, contradictions, and repetitions
in the same section does not qualify as "clarifying text".

Strike the section.   Or, rewrite it to remove the errors, contradictions
and repetitions.

> 
> >> 
> >> >Section 3.12
> >> >
> >> >  Strike this section.  It precludes DE which is allowed as an alternative
> >> >  in the the RFC.  SE and DE were never intended to interoperate with each
> >> >  other.  IPSPs that communicate with each other must operate in either SE
> >> >  mode or DE mode, but not a mixture.  As there is no interoperability
> >> >  concern, there is no reason to preclude DE.
> >> 
> >> We should make one option mandatory as it is right now (SE, as it is
> >> simpler) and have the DE as optional, since there are implementations that
> >> use it. The best way forward to ensure a minimum interoperability... 
> >
> >I disagree.  The best way forward is to write a proper extension draft
> >for peer-to-peer operation as was agreed when we let the RFC pass WG LC.
> >SE does not required any special IPSP description in the draft (because
> >it is exactly the way that an ASP talks to an SGP), and is already
> >supported by any node that supports ASP or SG operation.  IPSP is optional.
> >The only special treatment required for IPSP operation is DE, therefore
> >I take it that DE is clearly optional.
> >
> >So there is really no need to go to all that extent, all you are saying
> >is that SE is already there and DE is optional which is what was agreed
> >at WG LC and already reflected in the RFC.  I can give you pointers to
> >message threads if you would like to look back.
> >
> >Please strike the section.
> 
> Hopefully, there will be more comments on IPSP.  In regards to the SG-SG I-D,
> Tolga recently pitched that it move forward as a WG doc and I certainly support
> that.

Then let's strike this section and move these issues to the extension draft
as was agreed at LC.

If the WG, and particularly the WG chair and editors of these documents
don't start honoring some of the "promises" that were made at LC that
persuaded us into letting the drafts pass WG LC with outstanding issues,
I for one will certainly never let another RFC pass WG LC again with
outstanding issues.  That includes the IG.

This document (the IG) appears filled with implementation concerns rather
than interoperabiltiy issues.  That would be fine if the implementations
concerns were not being permitted to make "MUST" and "SHOULD" requirements.

If any implementor cannot see how to implement DE, the recomendation to
them is to not implement it.  The last thing that should be done is to
say that DE is "forbidden" because some implementors are short-signted.
Yet, this seems to be the case.

Strike the section.  Some implementors wish to implement the DE OPTION
as described in the RFC.  It is not the IGs place to remove this option
at this point.  Strike the section.

> 
> >> 
> >> 
> >> >Section 3.13
> >> >
> >> >  There are situations in which a MGMT message (Notify) must be sent
> >> >  on a stream other than "0".  This is where a Notify is required to
> >> >  be synchronized with ASPTM and DATA messages.  For example, when an
> >> >  SG sends Notify("Alternate ASP Active") it serves to move the active
> >> >  ASP to the ASP-INACTIVE state (just as an ASP Inactive Ack would do)
> >> >  and the ASP should not process DATA received after the Notify.  To
> >> >  avoid the race condition between a Notify("Alternate ASP Active")
> >> >  on stream "0" with data not on stream "0" would require sending the
> >> >  Notify on the same stream as the data.
> >> 
> >> Are you recommending that Notify be sent on all non-zero streams 
> >> in this case?  Otherwise, how do you select which stream to use?
> >
> >See draft-bidulock-sigtran-corid-00.txt for synchronization of data
> >flows across multiple streams.  Without those procedures, sending
> >DATA for one AS on multiple streams will result in a high probability
> >of mis-sequencing under failover conditions which an MTP-User is not
> >prepared to accept.
> >
> >If you use CORID, the Notify would only have to be sent on one of the
> >synchronized streams.
> 
> CORID no longer exists and cannot be considered normative.

You asked

>> how do you select which stream to use?

I was answering your question, not making a normative reference.

Besides, what has "normative" got to do with the discussion?--The IG
is in draft and cannot be considered normative.

> 
> >If you don't, you will get mis-sequencing of DATA if you send on
> >multiple streams regardless of which stream you choose for Notify.
> >
> >The RFC/IG should not tell the SG which stream it must send Notify on
> >otherwise, it will preclude the SG from synchronizing Notify with DATA.
> 
> I don't have a major problem with removing this restriction... again, hopefully
> we'll get more feedback.

Anybody disagree?  No?  Good.  Please remove the restriction.

This is a draft for heaven's sake, not a final draft of an RFC hanging on
being advanced.  Make the edits.  If someone disagrees they can bring it
up now, on the next version of the draft, or at LC, or not at all.

> 
> >> 
> >
> >> 
> >> 
> >> >Section 3.14
> >> >
> >> >  Remove "For AS-SG communication this parameter MUST NOT be used."
> >> >
> >> >  ASP Id in the ASP Up Ack would serve to identify the SGP in cases
> >> >  where Middle boxes and NAT make it impossible for the ASP to determine
> >> >  to which of several SGP it has connected.
> >> 
> >> Can you explain how the ASP would determine which SGP is had connected
> >> to based on ASP ID in the case of a NAT.  
> >
> >The ASP would determine which SGP it had connected to by examining the
> >ASP Id (really the SGP Id) returned in the ASP Up Ack.  This Id would
> >uniquely identify the SGP to the ASP.
> 
> Since the ASP is acting as the client, it will have to have an external address/port
> configured for the SGP in order to establish the association.  As SGP acts as
> a server behind the NAT, this external address/port would be statically provisioned
> to an internal address/port.  Allowing the SGP to return a SGP ID does not seem
> to provide much.

> Since the ASP is acting as the client
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Incorrect assumption.  The ASP is not required to act as a client from the
SCTP perspective.  The SG may also connect to the ASP.  In which case, it is
still the responsibiliy of the ASP to send ASP Up, but it does not necessarily
know which SGP has connected to it if dynamic port assignment and address
translation is being performed on the SGP side.

> 
> >> 
> >> 
> >> >Section 3.15
> >> >
> >> >  The change from MAY to SHOULD NOT is against consensus on the n+k
> >> >  model as described in the RFC.  Unless the "n" value is required to
> >> >  be provisioned by the SG and somehow coordinated between ASP and SG
> >> >  the SG cannot know when to do this an SHOULD NOT is not appropriate.
> >> >  "MAY chose not" was deemed appropriate in the last long discussion
> >> >  on this topic.
> >> >
> >> >  Please review post-LC threads on n+k and change SHOULD NOT back to
> >> >  "MAY chose not".
> >> 
> >> Wasn't there a discussion (thread "m3ua: IG : n+k redundancy - AS state
> >> machine") in which it was concluded that n is *required*. The SHOULD NOT is
> >> in line with that discussion. If "n" is required, it means that SG will have
> >> to know that value. It is a clear consequence.
> >
> >No, it was determined that "n" would be required to perform these
> >procedures.  Rather than require "n" (because many implementations
> >have no use for it), we made the procedure OPTIONAL with the MAY
> >that you just removed!  Please put it back the way it was before.
> 
> I'll review the thread.

Thank you for considering my lowly comments as worthy, master, for you
to perform a review, and for possibly considering making a change to
what must be an almost perfect document: because at revision number 1
it must have already been so thoroughly reviewed as to represent world
concensus. ;)

--brian

-- 
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: Wed, 15 Jan 2003 03:35:30 -0700

Resend...

Ken Morneault wrote:                             (Thu, 02 Jan 2003 09:05:39)
> 
> 
> Brian,
> 
> Please address your concerns to the entire group as your proposed
> change is something for all to discuss.
> 
> Regards,
> 
> Ken

SIGTRAN,

Section 3.2.

What does it matter if the SGP sends "Unsupported Message Type" or
"Unsupported Message Class"?  Acutally, if we ever add a message to the class,
"Unsupport Message Class" might no longer be correct, whereas "Unsupported
Message Type" survives the addition of new message types to the class.

Also, as the only necessary piece of information given in the Error message
is the Message Class and Type, why force an implementation to include the
first 40 bytes of the message?  That's ridiculous.  All that needs to be
included a couple bytes of the message header.

Also, there is no more need to correlate this error than others.  The
ASP is obviously misconfigured (it figures it can register with an SGP
that does not even supoprt registration), so it really doesn't matter
what happens to it: there are many ways to misconfigure an ASP so that
it will not be caught by the protocol.

Please strike section 3.2.

Also note that M2UA and SUA also use the same text.  It makes no sense to
have M3UA act differently in this regard than M2UA and SUA.

--brian

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 15 Jan 2003 13:56:48 +0200

Brian,                                                                     

                                                                            
   Incorrect assumption.  The ASP is not required to act as a client from   
   the                                                                      
   SCTP perspective.  The SG may also connect to the ASP.  In which case,   
   it is                                                                    
   still the responsibiliy of the ASP to send ASP Up, but it does not       
   necessarily                                                              
   know which SGP has connected to it if dynamic port assignment and        
   address                                                                  
   translation is being performed on the SGP side.                          
   [TOLGA] In fact in such a case I think there might be another problem.   
   How will ASP fill AspId in ASPUP, without knowing which SGP is           
   connected?                                                               
   What was the reason to allow SGPs to connect to ASPs -just not to bring  
   a restriction unless it is really required?- ?.