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

From: Tolga Asveren <[email-masked]>
Date: Tue, 26 Nov 2002 14:58:33 -0800 (PST)

Hi Herve,

IPSP discussions were done mainly on SIGTRAN WG list.
Off-list discussions you were mentining were more
focused on SG-SG communication, because there the
tendency was to support intra-IP communication with a
peer-to-peer protocol based on PC (kind of M3PA).
For intra-IP communication, IMO the key point is that
it is a peer to peer model. I think, only SG-SG(or
IP-SP to IP-SP, where IP-SP stands for IP-Signalling
Point) and SE allow this. DE is combination of two
client/server relationships, which IMO one even can
model as independent of each other.

    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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 26 Nov 2002 16:30:24 -0800 (PST)

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