(M2PA) M2PA Implementor's Guide Kickoff

Hello All,
 
As Lyndon Ong stated in a prior post, I've agreed to lead the effort
in creating an M2PA Implementor's Guide. I am busy working on it, 
but I have not yet submitted a draft. When I do submit it, it will
have the lovely name 'draft-ietf-sigtran-m2pa-ig-00.txt'.
 
In the meantime, I would like to kick-off discussion and solicit ideas
for the following:
 
* preference for IG content (delta document vs. replacement document)
* specific defects and remedies
* clarifications
 
At the bottom of this post is a memo I drafted describing my proposals
for the IG, as well as the preliminary list of 'defects'. Comments
and questions are welcome.
 
Regards,
 
Jeff
 
========================================================================
===
M2PA Implementor's Guide: Defect Summary
v0.1
Jeff Craig
1/11/06
 
The primary goal of the M2PA Implementor's Guide (IG) is to identify and
fix RFC 4165 defects. The most important defects are those that can lead
to interoperability problems between M2PA peers. (Some would argue these
are the only defects.)
 
As lead editor, my proposed approach for the M2PA IG is: A M2PA RFC 
passage is defective if the community agrees that the passage is either
incorrect or unclear. Reasonable requests for clarification will be
honored.
 
I propose for the IG to address each defect by listing the applicable
original text followed by the new text. The applicable text may be
non-contiguous. This means that the IG will contain changes for the 
previous RFC, rather than replacing the RFC in its entirety.
 
------------------------------------------------------------------------
---
The following is a draft summary of defects that I have gathered from
the
SIGTRAN listserv archives, as well as from my company's experience
during M2PA development and deployment:
 
(ordered by M2PA RFC section)
 

 1) 1.7.3: Clarify that stream 0 in each direction SHOULD be given
       higher priority than stream 1 in each direction. Forward
       reference 4.1.8.
 
 2) 2.2.2: Clarify initial FSN per MTP3 standard.
 
 3) 2.3.1: Clarify that an "empty User Data message" is a 
       message having the Command Message Header, the User Data
       message type, the M2PA-specific Message Header, and no
       Message Data.
 
 4) 2.3.2: Provide a table that lists the equivant Q.703 MTP2 FISU
       or LSSU for each M2PA LS Message.
       
 4) 4: Clarify that interoperability between M2PA peers requires
       that each implementation meets the requirements of same 
       MTP2 specification. Clarify that the M2PA protocol does not
       provide a mechanism for determining the MTP2 variant
       implemented by the peer.
 
 5) 4.1.4: Distinguish M2PA behavior during Aligned Not Ready and
              Processor Outage state equivalents.
           Clarify M2PA sequence number synchronization procedure
              upon Processor Outage recovery.
           Clarify M2PA treatment of LS Ready during Aligned Not
              Ready and Processor Outage state equivalents.
           Address need for timer in support of sequence number 
              synchronization upon exiting Processor Outage state
              equivalent.
 
 6) 4.1.5: Clarify that after receiving LS Busy and prior to
    receiving LS Busy Ended non-empty M2PA User Data Message
    MUST NOT be sent and empty M2PA User Data Message (ACK) MAY be
    sent.
 
 7) 4.1.5: Clarify M2PA behavior during simultaneous local busy 
    and local processor outage conditions.
 
 8) 4.1.5: Clarify M2PA management of T7 when remote busy clears.
 
 9) 4.1.8: Clarify meaning of giving "higher priority" to the Link
    Status association stream.
 
10) 4.1.9: Clarify M2PA treatment of received messages having a
    higher (newer) version.
  
11) 4.2.1: Clarify M2PA treatment of FSN for non-empty User Data, 
    empty User Data, and Link Status messages.
 
12) 4.2.1: Clarify M2PA initial FSN based upon MTP2 variant.
 
13) 4.2.1: Clarify M2PA treatment of BSN for non-empty User Data, 
    empty User Data, and Link Status messages (in general), and
    Link Status Ready messages (in particular).
 
14) 5.4: Update Figure 16 to accurately decribe M2PA behavior during
    processor outage.
 
15) 5.4: Provide new figure depicting M2PA message flows during
    aligned not ready state equivalent.
 
16) NEW: Provide better recommendations for M2PA timer values, since 
    the cited MTP2 standards apply to dedicated physical transports
    having different characteristics (e.g. bit rates, latency) than
    SCTP networks.

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