Subject: FW: [Sigtran] IPSP issues

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 24 Apr 2002 18:29:11 +0200

Brian, 

What it's included in the text that Tolga sent is inter-IP communication using SGs but not IPSP communication... 

IPSP does not need SG-SG communication. SG-SG communication is another feature that can be use to communicate two ASPs using SGs. IPSP comm. does not either need a single SG. Your proposal a longer and slower way of transferring information and also needing extra SGs. 

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 6:24 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: [email-masked]
> Subject: Re: [Sigtran] IPSP issues
> 
> 
> Javier,
> 
> I was meaning that "IPSP Considerations" should be removed in
> favor of the "IPSP Extension Draft" which addresses the issue
> with SG-SG communication.
> 
> --brian
> 
> On Wed, 24 Apr 2002, Javier Pastor-Balbas (ECE) wrote:
> 
> > Hi Brian, 
> > 
> > You don't have to implement IPSP if you don't want. Just 
> say it in your
> > product description.
> > 
> > Cheers // Javier.
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, April 24, 2002 6:12 PM
> > > To: Tolga Asveren
> > > Cc: [email-masked]
> > > Subject: Re: [Sigtran] IPSP issues
> > > 
> > > 
> > > Tolga,
> > > 
> > > I agree.  Existing "IPSP Considerations" should be removed.
> > > 
> > > --brian
> > > 
> > > 
> > > Tolga Asveren wrote:                                        
> > > (Wed, 24 Apr 2002 08:33:46)
> > > > Javier,
> > > > 
> > > > I still stick with the decision from recent IPSP discussions:
> > > > 
> > > >      -----              -----
> > > >    //     \\          //     \\
> > > >   |  ASP    |        |  ASP    |
> > > >   |  Cloud 1|        |  Cloud 2|
> > > >    \\     //          \\     //
> > > >      --+--              --+--
> > > >        |                  |
> > > >        |                  |
> > > >     +--+--+            +--+--+
> > > >     | SG1 +------------+ SG2 |
> > > >     +--+--+            +--+--+
> > > >        |                  |
> > > >        |                  |
> > > >        |                  |
> > > >        |     +-----+      |
> > > >        +-----+ SG3 +------+
> > > >              +--+--+
> > > >                 |
> > > >                 |
> > > >               --+--
> > > >             //     \\
> > > >            |  ASP    |
> > > >            |  Cloud 3|
> > > >             \\     //
> > > >               -----
> > > > 
> > > > The communication inside ASP clouds is based on existing ASP/SGP
> > > > functionalities. How big or how small one ASP cloud is 
> configuration
> > > > dependent.
> > > > I still don't think, we should try to create a new process 
> > > type "IPSP",
> > > > because it is not necessary.
> > > > If people feel the need that some sample configurationsa 
> > > are put to the
> > > > draft, that is fine. But in my opinion, all of those "IPSP 
> > > considerations"
> > > > sections are not needed.
> > > > 
> > > >     Tolga
> > > > 
> > > > > -----Original Message-----
> > > > > From: Javier Pastor-Balbas (ECE)
> > > > > [mailto:[email-masked]]
> > > > > Sent: Wednesday, April 24, 2002 4:24 AM
> > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > Subject: RE: [Sigtran] IPSP issues
> > > > >
> > > > >
> > > > > Hi Tolga,
> > > > >
> > > > > This drawing is being more and more similar to what I 
> think. But
> > > > > I still don't need all the SGP functionality in my 
> pure IPSP. The
> > > > > same applies to the ASP funcitionality. If I only 
> implements IPSP
> > > > > communication I just need some parts that are common with 
> > > the pure ASP.
> > > > >
> > > > > I would prefer to draw the IPSP as a box. Including 
> all the ASP
> > > > > or all the SGP functionality in there is not necessary and it
> > > > > becomes a design decission.
> > > > >
> > > > > More comments below...
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > Sent: Tuesday, April 23, 2002 7:24 PM
> > > > > > To: [email-masked]
> > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > >
> > > > > >
> > > > > > Hi Javier,
> > > > > >
> > > > > > I didn't say a third node is necessary. I just want to point
> > > > > > out, already
> > > > > > defined functionalities are enough to handle communciation
> > > > > > both to SS7 and
> > > > > > to IP nodes.
> > > > >
> > > > > Agreed and that's what IPSP philosophy is based on.
> > > > >
> > > > > > For example your MSC most probably should look like:
> > > > > >
> > > > > >  +------------+
> > > > > >  |            |
> > > > > >  |            |
> > > > > >  |   X        |
> > > > > >  |            |
> > > > > >  |    +-------+
> > > > > >  |    |ASP    |
> > > > > >  |    +-------+
> > > > > >  |    |SGP    |
> > > > > >  +----+-------+
> > > > > >
> > > > > > What you put inside your node is an internal decision. The
> > > > > > protocol just
> > > > > > defines the relationship between endpoints, and with 
> > > already defined
> > > > > > endpoints, it works.
> > > > > >
> > > > >
> > > > > It works, but including all the ASP and SGP 
> functionality inside
> > > > > an IPSP, it's more than you really need.
> > > > >
> > > > > > If you agree that a simple configuration is better, I think
> > > > > > it is better
> > > > > > that you also consider all of the necessary details, to draw
> > > > > > the ========
> > > > > > between ASs. I think it is more complicated than it 
> > > appears first.
> > > > > >
> > > > >
> > > > > Well, let's study this complexity and solve the open 
> points taken
> > > > > the current RFC as the base...  :-D
> > > > >
> > > > >
> > > > > Cheers // Javier.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >     Tolga
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, April 23, 2002 12:28 PM
> > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi Tolga,
> > > > > > >
> > > > > > > I agree that your configuration can work. But 
> what I'm also
> > > > > > > looking for is simplicity. If I want an MSC to 
> > > communicate with
> > > > > > > an HLR, I want the underlying protocols of that 
> > > particular nodes
> > > > > > > do all the work for me. I don't want to include a 
> third node.
> > > > > > >
> > > > > > > In your drawing using the IPSP communication it will 
> > > go thru the
> > > > > > > direct path. This means easiest configuration and faster
> > > > > > transmission.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >   RK1: DPC=1-1-1       RK2: DPC=2-2-2
> > > > > > >   +------+            +------+
> > > > > > >   | AS 1 |============| AS 2 |
> > > > > > >   +--+---+            +--+---+
> > > > > > >      |                   |
> > > > > > >      |                   |
> > > > > > >      |                   |
> > > > > > >      |                   |
> > > > > > >      |                   |
> > > > > > >      |     +------+      |
> > > > > > >      +-----+ SG 1 +------+
> > > > > > >            +------+
> > > > > > >          RK1: DPC=1-1-1
> > > > > > >          RK2: DPC=2-2-2
> > > > > > >
> > > > > > >
> > > > > > > I don't really understand why you want to include 
> a third node
> > > > > > > there... What it is already defined works fine. 
> > > Include the SG 1
> > > > > > > you can also have a redundancy path but the primary 
> > > will be the
> > > > > > > "====" one. AS1 will select the shortest path 
> > > (association) among
> > > > > > > the available ones.
> > > > > > >
> > > > > > > I don't see any benefits from your scenario for an AS-AS
> > > > > > > communication point of view. The good point of 
> > > including a  SG is
> > > > > > > having connection to an SS7 network as well. BUt for 
> > > those cases
> > > > > > > you can use my configuration above what is optimized.
> > > > > > >
> > > > > > >
> > > > > > > Cheers // Javier.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, April 23, 2002 6:05 PM
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Javier,
> > > > > > > >
> > > > > > > > Again I think, we are saying the same thing with you.
> > > > > > > > Probably the only
> > > > > > > > difference is, in my opinion, it is not important 
> > > whether the
> > > > > > > > remote peer
> > > > > > > > you are sending messages to (for example 1-1-1) is in IP
> > > > > > > > domain or in SS7
> > > > > > > > domain. I think, the important point is (in the 
> context of
> > > > > > > > this discussion)
> > > > > > > > the behavior of the peer (not the remote endpoint, your
> > > > > > > > adjacent node) you
> > > > > > > > are sending the messages. Regardless of where the remote
> > > > > > > > endpoint is (IP
> > > > > > > > domain or SS7) , the messages and procedures 
> are the same.
> > > > > > > > For example, just as a very simple example, 
> let's consider
> > > > > > > > the following
> > > > > > > > configuration:
> > > > > > > >
> > > > > > > >  RK1: DPC=1-1-1       RK2: DPC=2-2-2
> > > > > > > >  +------+            +------+
> > > > > > > >  | ASP1 |            | ASP2 |
> > > > > > > >  +--+---+            +--+---+
> > > > > > > >     |                   |
> > > > > > > >     |                   |
> > > > > > > >     |                   |
> > > > > > > >     |                   |
> > > > > > > >     |                   |
> > > > > > > >     |     +------+      |
> > > > > > > >     +-----+ SGP1 +------+
> > > > > > > >           +------+
> > > > > > > >         RK1: DPC=1-1-1
> > > > > > > >         RK2: DPC=2-2-2
> > > > > > > >
> > > > > > > > This is possible with existing m3ua draft, nd two
> > > > > > > > applications in IP domain
> > > > > > > > can communicate in such a way. They can also 
> > > communicate with
> > > > > > > > nodes in SS7
> > > > > > > > domain. When there are different operators involved and
> > > > > > > > configurations are
> > > > > > > > more complex, then one probably will want to have a
> > > > > > > > configuration with SG-SG
> > > > > > > > communication.
> > > > > > > >
> > > > > > > >    Tolga
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > [mailto:[email-masked]]
> > > > > > > > > Sent: Tuesday, April 23, 2002 11:35 AM
> > > > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Tolga, see below..
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > > > Sent: Tuesday, April 23, 2002 5:41 PM
> > > > > > > > > > To: [email-masked]
> > > > > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Javier,
> > > > > > > > > >
> > > > > > > > > > Personally I disagree that IPSP is described in 
> > > the current
> > > > > > > > > > draft. It is
> > > > > > > > > > just a group of sentences, which were put 
> there without
> > > > > > > > > > consensus and deep
> > > > > > > > > > thinking, because of time limitations.
> > > > > > > > > > The fact, that people could let their nodes 
> > > communicate in IP
> > > > > > > > > > domain in the
> > > > > > > > > > lastinteroperability event just shows me, 
> that this is
> > > > > > > > > > achievable with the
> > > > > > > > > > well defined SGP/ASP functionalities.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > It is achievable indeed, and it is based in 
> the SGP/ASP
> > > > > > > > > functionalities that were define in advance. But 
> > > the good thing
> > > > > > > > > is that you have and IP-node that can talk to an SG or
> > > > > > to another
> > > > > > > > > IP-node at the end .... :-D
> > > > > > > > >
> > > > > > > > > Cheers // Javier.
> > > > > > > > >
> > > > > > > > > > (I sent all of the messages of the recent IPSP 
> > > discussions as
> > > > > > > > > > a text file
> > > > > > > > > > attachment to the list, it waits approval 
> from moderator
> > > > > > > > > > because its size is
> > > > > > > > > > bigger than 40K)
> > > > > > > > > >
> > > > > > > > > >    Tolga
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: [email-masked]
> > > > > > > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > > > > > Javier Pastor-Balbas (ECE)
> > > > > > > > > > > Sent: Tuesday, April 23, 2002 11:22 AM
> > > > > > > > > > > To: [email-masked]'
> > > > > > > > > > > Cc: [email-masked]'
> > > > > > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi Brian,
> > > > > > > > > > >
> > > > > > > > > > > I'm aware of some of your discussions but I 
> > > just see your
> > > > > > > > > > > proposal as another configuration different from
> > > > > > what IPSP is.
> > > > > > > > > > > IPSP communication is already included in the RFC
> > > > > > as I explained
> > > > > > > > > > > below and has been successfully tested in the last
> > > > > > interop...
> > > > > > > > > > > It's just a matter of solving the concerns that
> > > > > > came up there.
> > > > > > > > > > >
> > > > > > > > > > > Cheers // Javier.
> > > > > > > > > > >
> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > From: Brian F. G. Bidulock 
> > > [mailto:[email-masked]]
> > > > > > > > > > > > Sent: Tuesday, April 23, 2002 4:32 PM
> > > > > > > > > > > > To: Javier Pastor-Balbas (ECE)
> > > > > > > > > > > > Cc: 'Tolga Asveren'; [email-masked]
> > > > > > > > > > > > Subject: Re: [Sigtran] IPSP issues
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Javier,
> > > > > > > > > > > >
> > > > > > > > > > > > I encourage you too look back in the 
> > > archives of the IPSP
> > > > > > > > > > mail list
> > > > > > > > > > > > where we have already discussed these issues.
> > > > > > > > Perhaps Tolga could
> > > > > > > > > > > > point to where those are.  As a group we 
> > > arrived at the
> > > > > > > > > > simpler model
> > > > > > > > > > > > of SG-SG communication (without 
> backhaul) using the
> > > > > > > > > > existing messages.
> > > > > > > > > > > >
> > > > > > > > > > > > --brian
> > > > > > > > > > > >
> > > > > > > > > > > > Javier Pastor-Balbas (ECE) wrote:
> > > > > > > > > > > > (Tue, 23 Apr 2002 15:30:07)
> > > > > > > > > > > > > Hi Tolga,
> > > > > > > > > > > > >
> > > > > > > > > > > > > See below....
> > > > > > > > > > > > >
> > > > > > > > > > > > > Cheers / Javier.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > > From: Tolga Asveren 
> > > [mailto:[email-masked]]
> > > > > > > > > > > > > > Sent: Tuesday, April 23, 2002 3:16 PM
> > > > > > > > > > > > > > To: [email-masked]
> > > > > > > > > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Javier,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To make this thread more productive 
> let me list
> > > > > > > > my concerns:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1) The fact, that "IPSP" is 
> described in a few
> > > > > > > > lines in M3UA
> > > > > > > > > > > > > > draft is in my
> > > > > > > > > > > > > > view enough evidence, that it just 
> > > reuses already
> > > > > > > > > > defined ASP/SGP
> > > > > > > > > > > > > > functionalities. I don't think there is a
> > > > > > need to give a
> > > > > > > > > > > > > > special name to
> > > > > > > > > > > > > > this, because it is just a special 
> > > configuration of
> > > > > > > > > > the existing
> > > > > > > > > > > > > > functionalities. Of course, different people
> > > > > > might have
> > > > > > > > > > > > > > different opinions
> > > > > > > > > > > > > > on that issue.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > About the special name I agree with 
> you that no
> > > > > > new names
> > > > > > > > > > > > were needed. I prefer to call it ASP-ASP
> > > > > > > > > > > > > Note about the RFC names:
> > > > > > > > > > > > > AS
> > > > > > > > > > > > > IPSP: node that communicates with another IPSP
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 2) I don't necessarily agree with 
> your sentence
> > > > > > > > "IPSP is an
> > > > > > > > > > > > > > IP-only node".
> > > > > > > > > > > > > > In the recent IPSP discussions, the question
> > > > > > > > which everybody
> > > > > > > > > > > > > > was asking was
> > > > > > > > > > > > > > "Can I have an aasociation between 
> IPSP and SGP,
> > > > > > > > what about
> > > > > > > > > > > > > > IPSP and ASP?".
> > > > > > > > > > > > > > That is also one of the reasons, why I 
> > > like to see it
> > > > > > > > > > as a special
> > > > > > > > > > > > > > configuration of ASP/SGP, because, in 
> > > such a case the
> > > > > > > > > > > > > > relationship between
> > > > > > > > > > > > > > endpoints is well defined.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > In fact you may be right. I'll try to 
> remake my
> > > > > > > > point better:
> > > > > > > > > > > > >
> > > > > > > > > > > > > IPSP is not and IP-node itself. "IPSP
> > > > > > communication" is the
> > > > > > > > > > > > "procedure" (using M3UA messages) that two AS
> > > > > > (i.e IP nodes)
> > > > > > > > > > > > need to use to talk among them.
> > > > > > > > > > > > > And AS-SG procedures are the ones that an AS
> > > > > > has to use to
> > > > > > > > > > > > talk to an SG.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We can think of ASP and IPSP as roles.The
> > > > > > implementation of
> > > > > > > > > > > > an AS in processes is as follows:
> > > > > > > > > > > > > 	- An AS implementation is 
> called ASP if it
> > > > > > > > > > talks with and SGP
> > > > > > > > > > > > > 	- An AS implementation is called IPSP
> > > > > > if it talks to
> > > > > > > > > > > > another AS implementation (also called IPSP)
> > > > > > > > > > > > >
> > > > > > > > > > > > > It can be possible that an AS can talk to 
> > > both kind of
> > > > > > > > > > > > nodes at the same time: an SG and another 
> > > AS. In that case
> > > > > > > > > > > > the implementation of that AS (what we call 
> > > process) will
> > > > > > > > > > > > take the roles of ASP and IPSP at the same time.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I know this nomenclature is not very clear. In
> > > > > > fact I tried
> > > > > > > > > > > > to change the term "IPSP communication" 
> for "ASP-ASP
> > > > > > > > > > > > Communication" but some folks preferred to 
> > > have different
> > > > > > > > > > > > names to differenciate both situations. But 
> > > anyway in the
> > > > > > > > > > > > draft it is said that "an IPSP serves an AS" in
> > > > > > the same way
> > > > > > > > > > > > that it is said that "an ASP serves an AS".
> > > > > > > > > > > > >
> > > > > > > > > > > > > Therefore we can conclude that it is not 
> > > possible to
> > > > > > > > > > > > connect an ASP with an IPSP, since this 
> are roles
> > > > > > that the AS
> > > > > > > > > > > > implementation can have. The AS is the one that
> > > > > > can be called
> > > > > > > > > > > > IP-node.  :-D
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hope this clarifies a little more...  :-/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Your main concern is -as far as I 
> > > understand- that SGP
> > > > > > > > > > > > > > functionality has
> > > > > > > > > > > > > > some components, which are not necessary for
> > > > > > > > "IPSP" case. For
> > > > > > > > > > > > > > which parts
> > > > > > > > > > > > > > are you concerned?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I hope the discussion above clarifies my 
> > > point... :-D
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > See it as the following:
> > > > > > > > > > > > > > > If you add to an AS the functionality 
> > > needed for an
> > > > > > > > > > SG to send
> > > > > > > > > > > > > > > messages to an AS, and you mix it 
> > > according with
> > > > > > > > > > the M3UA RFC,
> > > > > > > > > > > > > > > you'll have an IP node that can talk 
> > > to an SG but
> > > > > > > > > > also DIRECTLY
> > > > > > > > > > > > > > > to another IP-node. It is what is 
> > > already defined
> > > > > > > > > > and it works
> > > > > > > > > > > > > > > fine. It worked fine in the last 
> > > interop. The open
> > > > > > > > > > issue we have
> > > > > > > > > > > > > > > is to decide the start-up of the 
> > > connection, but the
> > > > > > > > > > > > rest doesn't
> > > > > > > > > > > > > > > need any urgent modification...
> > > > > > > > > > > > > > That is also exactly what I am 
> saying. More and
> > > > > > > > more I have
> > > > > > > > > > > > > > the feeling, the
> > > > > > > > > > > > > > main difference is, you want to give this
> > > > > > thing a new name
> > > > > > > > > > > > > > and I don't.
> > > > > > > > > > > > > > Well, this is not a big issue :-)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >     Tolga
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> _______________________________________________
> > > > > > > > > > > > > > Sigtran mailing list
> > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > > 
> https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> _______________________________________________
> > > > > > > > > > > > > Sigtran mailing list
> > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Brian F. G. Bidulock
> > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > http://www.openss7.org/
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Sigtran mailing list
> > > > > > > > > > > [email-masked]
> > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Sigtran mailing list
> > > > > > > > > > [email-masked]
> > > > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Sigtran mailing list
> > > > > > > > [email-masked]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 

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