Subject: Summary (hopefully) was: IPSP Text (take 3?)

From: [email-masked]
Date: Tue, 20 Nov 2001 09:58:22 +0200

Hi all,

There have been ALOT of emails on this subject, and I believe that
they have not helped to clarify things.  Some general comments:

1) RCs may or may not be used.
2) Exact nature of an IPSP (SG vs. AS, SGP vs. ASP) is very
   close to an implentation issue.
3) M3UA/SUA SHOULD (MUST?) NOT get into description of how
   admistrators administer/provision RKs & RCs.

Additionally, there have been comments about:
1) Necessity of a single ended approach.
2) Necessity of a double ended approach.
3) Extremely complicated scenarios (multiple AS, multiple ASP,
   mixed IPSP/SGP nodes, etc).

To summarize what I think needs to be addressed in the next version
of M3UA & SUA are:
1) Minimal text in section 4, for IPSP considerations.
2) This minimal text should be reciever driver (what a reciever
   does when it recieves an ASP UP, ASP ACK, etc).  

The result would be:
1) Simple pre-provisioned connections could be supported.
2) Building blocks for more complex behaviors would be in the
   drafts.
3) Additional work should be done in a seperate draft which
   discusses the usages of RKs and RCs.

I believe that that text I sent out (under the subject of 
IPSP (take 3)) should meet this goal.  While I know that there
have been some comments on it, most of the discussion has
veered off.  Now, unless someone can propose an acceptable
solution/resolution to this, my intention is to go forward
with proposed text for both M3UA and SUA.

Comments?
John

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 20 Nov 2001 09:53:04 +0100

Hi all, 

I fully support John's view. M3UA and SUA will have a common and very open text.

Cheers // Javier

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 8:58 AM
> To: sigtran
> Subject: Summary (hopefully) was: IPSP Text (take 3?)
> Importance: High
> 
> 
> Hi all,
> 
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Nov 2001 03:58:57 -0600

John,

Please see comments below...

John Loughney wrote:                   (Tue, 20 Nov 2001 09:58:22)
> with proposed text for both M3UA and SUA.

Please address some of the comments made on the proposed text
as follows...

John Loughney wrote:                   (Thu, 15 Nov 2001 14:31:44)
> Hi all,
> 
> I've reviewed Javier's text, and I have made some modifications.  I've
> removed text.  Please comment.  
> 
> best regards,
> John
> 
> ============================================================================
> ======
> 
> 1.4.2.4 Message Distribution at the IPSP 
> 
> [I suggest we delete this text, it is mostly operational in nature.  If it
> is truly needed, I think we should simplify it.
> 
> 4.3.3. IPSP Considerations (ASP State Transition Diagram)
> 
> For IPSP signalling, the state transition is diagrammed in Figure F.
> 
> Figure F: ASP State Transition Diagram (Per AS for AS-AS communication) 
>     
>                                       +--------------+  
>                                       |              | 
>                +----------------------|  ASP-ACTIVE  | 
>                |      Other   +-------|              | 
>                |   ASP in AS  |       +--------------+ 
>                |   Overrides  |           ^     | 
>                |              |    ASP    |     | ASP 
>                |              |    Active |     | Inactive 
>                |              |           |     v 
>                |              |       +--------------+ 
>                |              |       |              | 
>                |              +------>| ASP-INACTIVE | 
>                |                      +--------------+ 
>                |                          ^     | 
>      ASP Down/ |                 ASP Up / |     | ASP Down / 
>  ASP Down Ack/ |              ASP Up Ack  |     | ASP Down Ack /
>      SCTP CDI/ |                          |     | SCTP CDI /
>        SCTP RI |                          |     | SCTP RI
>                |                          |     v
>                |                      +--------------+ 
>                |                      |              | 
>                +--------------------->|   ASP-DOWN   | 
>                                       |              | 
>                                       +--------------+
> 
> The AS state diagram for the AS-SG case is applicable for IPSP communication

Delete this diagram.  It is not applicable to both the ASP/IPSP --> SG/IPSP
and SG/IPSP --> ASP/IPSP models.  The current ASP state diagram (viewed
with from the ASP or SG perspectives at an IPSP is sufficient.)

> 
> 4.3.4.1.2 IPSP Considerations  (ASPUP)
> 
> A single ASP UP and ASP UP Ack is needed to start communication between two
> IPSPs.  When an IPSP recieves an ASP UP, it should mark the peer as
> ASP-INACTIVE and return an ASP UP Ack message, if it is not already in the
> ASP_INACTIVE state, and informs Layer Management with an M-ASP_UP
> confirmation primitive.  An ASP recieving an ASP UP Ack message should mark
> the peer as ASP-Inactive, if it is not already in the ASP_INACTIVE state,
> and informs Layer Management with an M-ASP_UP confirmation primitive. 
> 
> If for any local reason (e.g., management lock-out) the IPSP-B cannot
> respond with an ASP Up Ack message, it responds to an ASP Up message with an
> Error message with Reason "Refused - Management Blocking" and leaves IPSP-A
> in the ASP-DOWN state.

Reword this as:

  An IPSP can be considered in the ASP-INACTIVE state after and ASPUP or
  ASPUP Ack has been received from it.  An IPSP can be considered in the
  ASP-DOWN state after and ASPDN or ASPDN Ack has been received from it.
  The IPSP may inform Layer Management of the change in state of the remote
  IPSP using M-ASP_UP or M-ASP_DN indication or confirmation primitives.

  If for any local reason (e.g., management lock-out) and IPSP cannot
  respond to an ASP Up message with an ASP Up Ack message, it responsds
  to an ASP Up message with an Error message with Reason "Refused -
  Management Blocking" and leaves the remote IPSP in the ASP-DOWN state.

> 
> 
> 4.3.4.4.1 IPSP Considerations (ASPAC)
>     
> Either of the IPSPs can initiate communication. When an IPSP recieves an ASP
> Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack
> message, if it is not already in the ASP-ACTIVE state. An ASP recieving an
> ASP Active Ack message should mark the peer as ASP-Active, if it is not
> already in the ASP-ACTIVE state.  Both IPSPs SHOULD be in the ASP-ACTIVE
> state before traffic can start to flow.

Delete "Both IPSPs SHOULD..."

> 
> 4.3.4.5.1 IPSP Considerations (ASPIA)
> 
> An IPSP can be considered in the ASP-INACTIVE state by a remote IPSP after
> an ASP Inactive message has been received from it. 

Reword as:

  An IPSP can be considered in the ASP-INACTIVE state by a remote IPSP after
  an ASP Inactive or ASP Inactive Ack message has been received from it. 

> 
> 4.3.4.6.1 IPSP Considerations (NTFY)
> 
> Notify works in the same manner as in the SG-AS case. One of the IPSPs can
> send this message to any remote IPSP that is not in the ASP-DOWN state.
> 
> 4.4.3 IPSP Considerations (REG/DEREG)
> 
> The Registration/Deregistration procedures work in the IPSP cases in the
> same way as in AS-SG cases. Each IPSP has to register its own RK in the
> remote IPSP.  Each IPSP deregisters itself.

Reword as:

  The Registration/Deregistration procedures work in the IPSP cases in the
  same way as in AS-SG cases.  An IPSP may register an RK in the remote
  IPSP.  An IPSP is responsible for deregistering the RKs that it has
  registered.

I believe that these changes would allow all of the possibilities discussed.

--brian

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

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 20 Nov 2001 09:14:58 -0800

These sound like reasonable changes to me, and
hopefully address some of Tolga's concerns as well.

Cheers,

Lyndon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 1:59 AM
To: sigtran
Cc: [email-masked]
Subject: Re: Summary (hopefully) was: IPSP Text (take 3?)

John,

Reword this as:

Reword as:

Reword as:

--brian

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 20 Nov 2001 19:41:21 +0100

Hi, 

As the commitment was allowing both single-ended and double-ended, three more small changes are needed to allow double ended. See below...

> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 6:15 PM
> To: sigtran
> Subject: RE: Summary (hopefully) was: IPSP Text (take 3?)
> 
> 
> > A single ASP UP and ASP UP Ack is needed to start 
> communication between
> two
> > confirmation primitive.  An ASP recieving an ASP UP Ack 
> message should
> mark
> > respond with an ASP Up Ack message, it responds to an ASP 
> Up message with
> an
> > Either of the IPSPs can initiate communication. When an 
> IPSP recieves an
> ASP

Some more minor changes below:

- remove "if it is not already in the ASP-ACTIVE state". This is mainly to be consistent with the text in chapter "ASP Active Procedures", paragraph 5.
- In "ASP Active Ack message should mark the peer as ASP-Active" change "should" for "may".
- also add: "In the case that an IPSP serves more than one AS, an interchange of ASPAC messages from each end can be performed in order to select which ASs are required to activate".

In this we allow both, as committed.

Cheers // Javier.

---