Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Thu, 28 Nov 2002 16:55:49 +0100

Hi Tolga,

If using static RC, SE IPSP works, but requires a lot of different RKs for
the same local AS. This is not the case for DE IPSP.

If using dynamic registration, the race conditions in SE IPSP will prevent
it to work, hence the need for DE IPSP.

We think that both large scale configurations and dynamic registration (not
necessarily at the same time) will be deployed, and we therefore feel that
DE IPSP is needed.

To add on the type of configuration that we have requests for: the large
scale configuration that we are mentionning above includes a mix of IPSP and
ASP/SG. Some ASP will definitively talk to SGs AND to IPSP at the same time.
In such a case another argument for the dynamic registration and the DE mode
is to configure the local AS only in the RK (DPC+SI) in much the same way
for the IPSP behavior and for the pure ASP behavior. So to not make much
difference from a network configuration standpoint.

From an implementation stand point we think that this is more flexible to
have two state machines coexisting (one for the IPSP/ASP side and one for
the IPSP/SG side) and some consolidation process on top of those two state
machines than having a third hybrid state machine in the game. From a design
stand point, we feel this is more flexible and reliable approach.

Best Regards,
Herve

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 1:30 AM
> To: [email-masked]
> Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> Resending, with some additions......
> 
> Hi Herve,
> 
> Most of IPSP discussions were done on the SIGTRAN WG
> list. The ones you mention in your message were more
> about SG-SG communication, because there the tendency
> was to use that model for intra-IP communication.
> IMO, for intra-IP communication, the key point is to
> define a peer-to-peer relationship. This can be
> achieved either with SE model or with SG-SG
> communication (kind of M3PA, which defines
> relationship between IP-SPs, where IP-SP stands for
> IP-Signalling point). DE is a client/server model, and
> in fact this kind of relationship between nodes is
> already defined for ASP/SGP communication.
> Now it seems to me your real concern is about number
> of RKs, instead of some race conditions during dynamic
> registration(?)
> 
>     Regards,
>      Tolga
> 
> --- "PELLAN,HERVE (HP-France,ex1)"
> <[email-masked]> wrote:
> > Hi Tolga,
> > 
> > > -----Original Message-----
> > > From: Tolga Asveren
> > [mailto:[email-masked]]
> > > Sent: Monday, November 25, 2002 8:55 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] Sigtran Plugtest
> > SUA/M3UA/M2UA/IUA - Day 2
> > > 
> > > 
> > > After long discussions the consensus was that IPSP
> > is
> > > intended to be AS-to-AS. IMO, DE does not fit this
> > > model, so my personal preference is to keep IPSP
> > as it
> > > is.
> > 
> >  This is actually the point that we would like to
> > discuss with you.
> > 
> >  Unfortunately we didn't follow the discussion that
> > occured, as far as I
> > remember on a separate mailing list (by the way, is
> > there a way to access
> > the mail archive now). At the first plugtest,
> > implementor's consensus was
> > that the double ended model was more flexible than
> > the SE mode. 
> > 
> >  Since then, things are getting much clearer for HP
> > which got customers
> > requests which does not fit into the simple AS-to-AS
> > model which gets a
> > consensus on the mailing list and we do feel this
> > flexibility is now a MUST
> > for the IPSP-IPSP case. 
> > 
> >  We have requests to support AS-to-several AS
> > (namely hundred of AS): this
> > make dynamic registration especially useful and from
> > our perspective a MUST:
> > It allows to define the AS RK as DPC(,SI) instead of
> > having of hundred of
> > symetric RK (OPC+DPC).
> > 
> >  This is a real concrete business case. It has been
> > successfully tested in
> > interop sessions in DE mode. 
> > 
> >  Therefore, the DE mode must at least be kept in the
> > standard. 
> > If we get too far in the standard to drop the SE
> > mode, then both modes need
> > to coexist to address different architecture.
> > 
> > Best Regards,
> > Herve
> > 
> > > If the problem case with dynamic registration is
> > > presented in the forum (because till now it
> > wasn't),
> > > we might try to find a solution for it within the
> > > boundaries of current IPSP model.
> > > DE is totally a different model and thinking that
> > both
> > > SE/DE can coexist is not logical IMO.
> > > 
> > >    Regards,
> > >     Tolga
> > > 
> > > --- "PELLAN,HERVE (HP-France,ex1)"
> > > <[email-masked]> wrote:
> > > > 
> > > > > > 2.  Concern about the state of IPSP.  With
> > IPSP
> > > > as single-exchange,
> > > > > > there is an issue related to dynamic
> > > > registration.  General 
> > > > > consensus
> > > > > > is that dynamic registration needs to be
> > > > double-exchange to avoid
> > > > > > potential for race condition.  Thus, there
> > is a
> > > > desire to move back
> > > > > > to double-exchange.
> > > > > [TOLGA] What is exactly the problem scenario?
> > Is
> > > > the proposal 
> > > > > to move just
> > > > > dynamic registration to double exchange or the
> > > > whole IPSP model? 
> > > > 
> > > > Hi Tolga,
> > > > 
> > > > we know that there has been a lot of discussion
> > > > about the subject SE IPSP
> > > > vs. DE IPSP.
> > > > It is not our intention to re-open the technical
> > > > parts of these discussions.
> > > > However, as Ken indicated in his summary of the
> > 2nd
> > > > day of the plugtest,
> > > > there is an argument to be made to put DE IPSP
> > back
> > > > in the M3UA
> > > > implementor's guide:
> > > > 
> > > > 1. Both DE and SE IPSP are included in RFC 3332
> > > > 2. During the 3rd M3UA plug test, we have
> > > > successfully interoperated in DE
> > > > IPSP mode, both with static RCs configured and
> > with
> > > > dynamic registration of
> > > > Routing Keys.
> > > > 3. There was a clear consensus amongst those
> > present
> > > > at the plug test that
> > > > for an implementation that wants to use dynamic
> > > > registration, only DE IPSP
> > > > will work.
> > > > 
> > > > So, for these reasons, we would like to see the
> > M3UA
> > > > implementor's guide
> > > > modified to reflect the following rules:
> > > > 1. When using static configuration of RCs, both
> > SE
> > > > and DE IPSP are allowed
> > > > and the chosen mode must be configured on both
> > > > sides.
> > > > 2. When using dynamic registration of Routing
> > Keys,
> > > > only DE IPSP is allowed.
> > > > 
> > > > We propose the following texts:
> > > > 
> > > > 3.12 IPSP stuff
> > > > 
> > > > 3.12.1 Description of the problem
> > > > 
> > > >     ---------
> > > >     Old text: (Section 3.12.1)
> > > >     ---------
> > > > 
> > > >     At the 2nd M3UA Plugtest several concerns
> > were
> > > > raised about the non-
> > > >     interoperability of the two different IPSP
> > > > exchanges defined in M3UA.
> > > > 
> > > >     ---------
> > > >     New text: (Section 3.12.1)
> > > >     ---------
> > > >     
> > > >     At the 2nd M3UA Plugtest several concerns
> > were
> > > > raised about the non-
> > > >     interoperability of the two different IPSP
> > > > exchanges defined in M3UA.
> > > >     
> > > >     The mode of communication (SE or DE) MUST be
> > > > agreed between both peers. 
> > > >         
> > > > 
> > > >  3.12.2 Text changes to the document
> > > > 
> > > >     ---------
> > > >     Old text: (Section 4.3.1)
> > > >     ---------
> > > > 
> > > >     Figure 4: ASP State Transition Diagram, per
> > AS
> > > > 
> > > >                                       
> > > > +--------------+
> > > >                                        |        
> >    
> > > >  |
> > > >                 +----------------------| 
> > ASP-ACTIVE
> > > >  |
> > > >                 |      Other   +-------|        
> >    
> > > >  |
> > > >                 |   ASP in AS  |      
> > > > +--------------+
> > > >                 |   Overrides  |           ^    
> > |
> > > >                 |              |    ASP    |    
> > |
> > > > ASP
> > > >                 |              |    Active |    
> > |
> > > > Inactive
> > > >                 |              |           |    
> > v
> > > >                 |              |      
> > > > +--------------+
> > > >                 |              |       |        
> >    
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> _______________________________________________
> 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, 28 Nov 2002 13:26:25 -0700

HERVE,

Several comments:

PELLAN,HERVE (HP-France,ex1) wrote:                                           (Thu, 28 Nov 2002 16:55:49)
> the same local AS. This is not the case for DE IPSP.

It was shown that SE requires half the RKs of DE, so you will have
to justify this statement.
> it to work, hence the need for DE IPSP.

There is never a race condition when one side is statically configured and
the other dynamically registers.

> necessarily at the same time) will be deployed, and we therefore feel that

Perhaps you misunderstand SE.

> difference from a network configuration standpoint.

This is certainly not supported in the RFC.  A node acting as ASP and IPSP
is a relay point which is precluded for IPSP in the RFC.  This work was
deferred to extension draft.

> stand point, we feel this is more flexible and reliable approach.

This receive much discussion, and we decided that a third approach (SG-SG
communication or M3PA) was a preferrable design approach.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 28 Nov 2002 17:45:39 -0800 (PST)

Hi,

As I tried to point out several times:
a) DE is not a peer-to-peer model. In that model one
has two ASP/SGP client server relationships, and this
relationship is already defined. So, I think, one can
has such a configuration, without any addition to the
RFC. From M3UA protocol point of view, nothing special
is needed to be defined.  

b) I disagree with the argument that DE was part of
RFC and for that reason should be explictly stated as
an IPSP model. Similarly SCTP error detection method
has changed. Is there somebody around saying that the
old method MUST be supported because it was in SCTP
RFC?

c) A peer-to-peer relationship can exist between two
same types of stacks. So, it is either between two
M3UA-ASP stacks (SE model) or between two M3UA-SGP
stacks (SG-SG or M3PA).

    Tolga