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

From: Tolga Asveren <[email-masked]>
Date: Tue, 20 Nov 2001 05:53:03 -0800 (PST)

Hi,

Please see comments below.

  Tolga
> > 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
> >
> 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.)
[TOLGA] If we delete this modified state machine,
everything will be the same like in SG/ASP case. So, a
M3UA node won't need to know whether its peer is an
IPSP or SG. I totally support to delete it.
> >
> > 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.
[TOLGA] Just here I have a small confusion.
ASP-INACTIVE-ACK will be sent by SG functionality of
an IPSP. Then affect of this message will be on the
receiver, namely on the ASP functionality of the
receiving IPSP. I think this sentence should say "An
IPSP can be considered in the ASP-INACTIVE state by a
remote IPSP after an ASP Inactive message has been
received from it or if an ASP-INACTIVE-ACK is sent to
it by that remote IPSP.
> > 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/
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to 
> [email-masked]

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 20 Nov 2001 08:26:41 -0800 (PST)

Hi,

Please see a further comment below.

  Tolga

mark the peer as
it is not 
with an M-ASP_UP
UP Ack 
the 
confirmation 
lock-out) the 
an ASP 
Blocking" 
state after 
be 
been 
in state 
confirmation 
message, it 
Reason "Refused -
the 
> ASP-DOWN state.
[TOLGA] Using only one ASPUP to put ASP
functionalities of both IPSPs to INACTIVE state will
change the ASP state machine compared to regular
SG/ASP case. Why should we do this? It should be noted
that activeness/inactiveness is an attribute of ASP
functionalities of IPSPs. If ASPUP is initiated by
both of them, this corresponds exactly to existing
SG/ASP case. 
With one ASPUP, as I stated earlier, one should know
whether the peer it is communicating to is an IPSP or
SG, because according to that, different ASP state
machines should be used.
My proposal is to have the same state machine for ASP
for all of the cases, so always using double ASPUP,
like one would use, if one had two ASPs.
Please comment with any significant benefit(s), one
ASPUP approach is going to bring.
In general, I think all of the text about "IPSP
Considerations" should be removed, because it uses the
protocol unmodified (if one ASPUP approach is
removed). We can mention about it as a sample
configuration.

---