Subject: RE: [Sigtran] M3UA notify message

From: <[email-masked]>
Date: Fri, 24 Feb 2006 11:17:38 +0530

Tolga,
Well let me express in detail:
"A combined view of the AS is maintained across all SGPs serving that
AS. This means the state of AS would be maintained at SG. The sate of
ASPs serving the (above) AS should be coordinated/shared across all SGPs
serving the AS. Shared should not be taken as maintained. What I mean is
the SGPs are just aware of the state of a particular ASP at a particular
SGP in an AS. Only then they can have a combined view of AS"

Now, if you don't agree with the above, let's consider the redundancy
model n+k for AS. Here for simplicity I consider the value of n=2 and
k=0. Guess you would agree that as per this model the AS would be
considered active only when the number of active ASPs is 2.
Let's also consider 2 ASPs (ASP1 and ASP2) and two SGPs (SGP1 and SGP2)
for the above model. 

ASP1 ------------- SGP1 (sctp association established and ASP1 inactive)

ASP2 ------------- SGP2 (sctp association established and ASP2 inactive)

Now if we take your view into consideration, then even if the ASPs
become active at there respective SGPs (i.e. ASP1 at SGP1 and ASP2 at
SGP2), the AS will still not be active. Why? For your view the ASPs
states would not be shared across SGPs serving a common AS! And the
minimum required ASPs are 2 for AS to become active!! Do you think,
that's okay?? Isn't the redundancy model n+k takes the overall view of
AS at SG to support failover? I guess with your view into consideration,
the interoperability would be broken here as the AS would never become
active.

Alternatively, let's change the values. N=2 (still!) and K=1 and
introduce another ASP3 having association with SGP2 but currently
inactive. Now if SGP1 fails or ASP1 goes down, who do think would notify
to ASP3 of insufficient ASPs?(assuming ASPs in AS are not able to share
state information). Only SGP2 can do it and without the knowledge of the
combined AS view, can it?? And combined AS view at SGP2 can only be
arrived at with the ASP state sharing!!

Brian, your views?

Regards,
 
Prabind

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, February 23, 2006 6:47 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA notify message

Prabind,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2006 11:20 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA notify message
>
>
>
> I am still concerned about this statement from Tolga:
>
> " In any case, it is good that there is finally consensus regarding
that
> ASPSM/ASPTM procedures and associated state machines being independent
> on
> each SGP."
>
> If multiple SGPs are serving a single AS, then shouldn't the ASP
states
> also be shared across the related SGPs?
> Else if I am wrong then the following statement in section 1.4.1
should
> be amended to share the AS states only.
> " Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
>    remote AS/ASP states of each SGP SHOULD be coordinated across all
the
>    SGPs."
>
> Tolga, further considering the sahring of ASP states then, in the case
> of the interoperability issue (as you depicted), the rfc says that if
an
> ASP is already inactive the ASP-UP message would still be respnded by
an
> ack.
[TOLGA]So are you claiming that there won't be an interoperability issue
according to the message flow I sent? Please look to steps marked with
(1)
and (2). If one uses a global AS/ASP state which is SG-wide for
ASPSM/ASPTM
procedures, interoperability issues will arise. OTOH, with NTFY, there
is no
such danger, afterall it is just advisory.
>
> I think the things become simpler if we consider sharing of ASP states
> of a particular AS across all SGPs serving that AS.
>
>
> Regards,
>
> Prabind
>
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, February 23, 2006 6:53 AM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA notify message
>
> Brian,
>
> As long as it is not an ASPSM/ASPTM procedure, it is fine. I probably
> was
> not careful when using the term "M3UA procedures" because it includes
> pretty
> much everything.
>
> BTW, I still wouldn't call it "M3UA procedure on each SGP", because
SSNM
> is
> not sent independently by each SGP when status of a destination in SS7
> network changes. It is supposed to be sent only once, but this is
> besides
> the point for this thread.
>
> In any case, it is good that there is finally consensus regarding that
> ASPSM/ASPTM procedures and associated state machines being independent
> on
> each SGP.
>
>   Tolga
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, February 22, 2006 8:34 PM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] M3UA notify message
> >
> >
> > Tolga,
> >
> > By an SGP, making it an "M3UA procedure on each SGP".
> >
> > --brian
> >
> > Tolga Asveren wrote:
> >    (Wed, 22 Feb 2006 18:10:02)
> > > Yes, SSNM will be sent per SG.
> > >
> > > BTW, my messages from a few hours ago started just to arrive, not
in
> the
> > > order I sent them.
> > >
> > >    Tolga
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, February 22, 2006 6:26 PM
> > > > To: Tolga Asveren
> > > > Cc: [email-masked]
> > > > Subject: Re: [Sigtran] M3UA notify message
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > BTW it is used for sending SNMM from an SGP: another M3UA
> > > > procedure at an SGP.
> > > >
> > > > --brian
> > > >
> > > > Tolga Asveren wrote:
> > > >    (Wed, 22 Feb 2006 15:36:22)
> > > > > Brian,
> > > > >
> > > > > Please show where in the specification it says that
ASPTM/ASPSM
> > > > relationship
> > > > > is between ASP and SG?
> > > > >
> > > > >    Thanks,
> > > > >    Tolga
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Wednesday, February 22, 2006 3:50 PM
> > > > > > To: Tolga Asveren
> > > > > > Cc: [email-masked]
> > > > > > Subject: Re: [Sigtran] M3UA notify message
> > > > > >
> > > > > >
> > > > > > Tolga,
> > > > > >
> > > > > > Tolga Asveren wrote:
> > > > > >    (Wed, 22 Feb 2006 15:28:21)
> > > > > > > Barry,
> > > > > > >
> > > > > > > Let me retry to explain my position:
> > > > > > >
> > > > > > > Coordination of AS/ASP is necessary to create the unique
> > > > SPMC view. This
> > > > > > > does not mean that the coordinated state should be used
for
> > > > > > M3UA procedures
> > > > > > > on each SGP. Each SGP should maintain its own staet
machine
> > > > from ASP/SGP
> > > > > > > procedures point of view.
> > > > > > >
> > > > > >
> > > > > > Your statements conflict with the consensus that went into
> > > > > > the RFC as upheld by the mailing list discussion on the
> matter.
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > > --
> > > > > > 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
> > > >
> > > > --
> > > > 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
> > [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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 00:58:50 -0700

prabind.chaubey,

I think that you understand the situation well now.

Because AS state depends upon ASP state, it is really not
possible to coordinate AS state across multiple SGP without also
coordinating ASP state.  That is why I feel that Greg stated the
situation well in 1.4.1 when he said:

  "Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
   remote AS/ASP states of each SGP SHOULD be coordinated across all the
   SGPs.  Rerouting of traffic between the SGPs MAY also be supported."

Also note that we never required that a full-mesh of SCTP
associations be formed between ASPs and SGPs.  And, certainly,
as you illustrate below, the failure of an association (or two)
can reduce a full-mesh to a sparse set of SCTP associations
anyway.  A full mesh would likely only be for network
redundancy.  If I have 2 ASPs, 2 SGPs and 2 networks, the most
efficient arrangement from a performance/failure perspective
would be as follows:

  ASP1  -------network A------- SGP1
        \______network B______/
         ______network B_____/\
        /                      \
  ASP2  -------network A------- SGP2

In that way if only network A fails, each ASP is still connected
to a different SGP (for performance), and the same is true if
only network B fails.  If network B fails, the situation
degrades to

  ASP1  -------network A------- SGP1

  ASP2  -------network A------- SGP2

The ability of the system to operate, should not be adversely
affected by the loss off network B.  If the SG does not
coordinate AS/ASP state, in scenarios like the 2+k scenario you
detail, the system will not function to the same degree as that
where AS/ASP state is coordinated.  Good reason for the SHOULD.

Now, we did not go much farther than the statements in section
1.4.1 because there are a number of ways to implement the
necessary functionality without using things like "shared"
state.  These are implementation details.  An example of how to
coordinate state without sharing is to have each SGP proxy its
connected ASPs to other SGPs at a lower priority, so the
full-mesh situation looks like so:

At SGP1:
   SGP1 to ASP1 via netA - priority 1
   SGP1 to ASP2 via netB - priority 1
   SGP1 to ASP1 via SGP2 - priority 2
   SGP1 to ASP2 via SGP2 - priority 2

At SGP2:
   SGP2 to ASP1 via netB - priority 1
   SGP2 to ASP2 via netA - priority 1
   SGP2 to ASP1 via SGP1 - priority 2
   SGP2 to ASP2 via SGP1 - priority 2

When network B fails, the system would reduce to the following:

At SGP1:
   SGP1 to ASP1 via netA - priority 1
   x x x x x x x x x x x x x x x x x 
   x x x x x x x x x x x x x x x x x 
   SGP1 to ASP2 via SGP2 - priority 2

At SGP2:
   x x x x x x x x x x x x x x x x x 
   SGP2 to ASP2 via netA - priority 1
   SGP2 to ASP1 via SGP1 - priority 2
   x x x x x x x x x x x x x x x x x 

The actions taken to get there are:

   SCTP communication lost from SGP1 to ASP2
   SGP1 marks ASP2 down
   SGP1 signals SGP2 that it can no longer proxy ASP2 (ASPDN equivalent)

   SCTP communication lost from SGP2 to ASP1
   SGP2 marks ASP1 down
   SGP2 signals SGP1 that it can no longer proxy ASP1 (ASPDN equivalent)

This approach also works well if the SG was to get partitioned
due to internal failure, and recovery from the internal
partitioning is smooth.  To a large degree the SGP can run a
local state machine without sharing state (in the "shared
memory" sense) under this arrangement, permitting geographical
distribution of SGP, particularly in administrative domains where
point code exhaustion is an issue.  Also, the M3UA (or SUA)
protocol can largely be reused for communicating between SGP.

But that's design and implementation.  There are, of course,
many other approaches to a solution for coordinating AS/ASP
state.

For the RFC, the word "coordinated" should suffice without going
into implementation details.

--brian

[email-masked] wrote:                           (Fri, 24 Feb 2006 11:17:38)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 09:12:12 -0500

Prabind,

First let me express that I am not insisting that my view was right -anymore
;-)-. It seems that the majority thinks the oter way, and that is fine -For
now, I still believe not using global-AS for ASPTM opertaions is
architecturally more clean-. Still let me explain how it would work, if no
global-AS state was used for traffic mode related ASPTM operations -so
please keep in mind that all comments below are from that interpretation
point of view-.

    Tolga

> Sent: Friday, February 24, 2006 12:48 AM
> To: [email-masked]; [email-masked]
[TOLGA]One would need associations between ASP1/SGP2 and ASP2/SGP1. I don't
think this is something horrible, on the contrary, I believe this is a good
thing to provide host redundancy. Otherwise, during host failures, there
would be internal traffic routing unnecessarily, e.g. consider
n=1/loadsharing traffic mode with your diagram, if ASP1 fails, all SS7
traffic from SGP1 first needs to be routed to SGP2, so that it can reach
ASP2, if there were an assocaition from ASP2 to SGP1, this wouldn't be
necessary-.
> arrived at with the ASP state sharing!!
[TOLGA]If both sides honor the same interpretation, I don't see any issues,
all ASPs would have associations to all SGPs and there won't be any problem
at all.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 09:23:34 -0500

Brian,

> Sent: Friday, February 24, 2006 2:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
[TOLGA]No, this is not really how it should be done -it is not wrong, but
one should be ready to face consequences with such a setup-. I would expect
both networks to be used between each peer with SCTP multihoming. We
discussed this several times  that SCTP multihoming with multiple networks
is practically necessary for a carrier grade environment.
>   ASP2  -------network A------- SGP2
[TOLGA]If SCTP multihoming is used properly, there won't be any isolation
because each STP association would utilize both networkA and networkB.
> where AS/ASP state is coordinated.  Good reason for the SHOULD.
[TOLGA]If SCTP multihoming is used utilizing both networks, ability of the
system is not affected at all when networkB fails.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 12:54:24 -0700

Tolga,

I cannot agree with you or subscribe to the view that an
association will never fail simply because of multihoming.

--brian

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 09:23:34)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 12:58:02 -0700

Tolga,

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 09:12:12)

> ASP2, if there were an assocaition from ASP2 to SGP1, this wouldn't be

There has never been a requirement for full-mesh associations in the UAs.

(And associations _can_ fail.)

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 14:59:37 -0500

Brian,

Of course associations can fail. If they fail due to a host failure, there
is no issue. Now, I assume you speak of premature failures.

Let's say, the probablity for an association to prematurely fail is p. If p
is not satisfying the requirements for a carrier grade environment, the SCTP
assocation is not fit to be used with M3UA -or one should be ready for bad
suprises-. There is nothing like something *never* fails, there is always a
probability for failure for anything, important is that it is under
tolerable limits.

But, we discussed all this in this mailing list and put something to
summarize the result:

http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt

Specifically Sections 2 and 3 in that draft.

   Thanks,
   Tolga

> Sent: Friday, February 24, 2006 2:58 PM
> To: Tolga Asveren
> Cc: [email-masked]
>    (Fri, 24 Feb 2006 09:12:12)
>
> > >

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 13:25:30 -0700

Tolga,

I prefer to read the RFC:

   In the example above, each signalling process (SGP, ASP or IPSP) is
   the end point to more than one SCTP association, leading to more than
   one other signalling processes.  To support this, a signalling
   process must be able to support distribution of M3UA messages to many
   simultaneous active associations.  This message distribution function
   is based on the status of provisioned Routing Keys, the status of the
   signalling routes to signalling points in the SS7 network, and the
   redundancy model (active-standby, load sharing, broadcast, n+k) of
   the remote signalling processes.

   For carrier grade networks, the failure or isolation of a particular
   signalling process should not cause stable calls or transactions to
   be lost.  This implies that signalling processes need, in some cases,
   to share the call/transaction state or be able to pass the call state
   information between each other.  In the case of ASPs performing call
   processing, coordination may also be required with the related Media
   Gateway to transfer the MGC control for a particular trunk
   termination. However, this sharing or communication of
   call/transaction state information is outside the scope of this
   document.

   This model serves as an example.  M3UA imposes no restrictions as to
   the exact layout of the network elements, the message distribution
   algorithms and the distribution of the signalling processes.
   Instead, it provides a framework and a set of messages that allow for
   a flexible and scalable signalling network architecture, aiming to
   provide reliability and performance.

--brian

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 14:59:37)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 15:45:23 -0500

Brian,

> Sent: Friday, February 24, 2006 3:26 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Let me quote for you also the beginning of this passage:
Appendix A

"A.1 Signalling Network Architecture

   A Signalling Gateway is used to support the transport of MTP3-User
   signalling traffic received from the SS7 network to multiple
   distributed ASPs (e.g., MGCs and IP Databases).  Clearly, the M3UA
   protocol is not designed to meet the performance and reliability
   requirements for such transport by itself.  However, the conjunction
   of distributed architecture and redundant networks provides support
   for reliable transport of signalling traffic over IP."

Although not a normative part of RFC, this section gives a pretty good
overview of how redundancy can be achieved when utilizing M3UA, i.e. "the
conjunction of distributed architecture and redundant networks"

Basically
distributed architecture ==> host redundancy
redundant networks ==> NIC/network redundancy

And it continues as follows:
"To meet the stringent SS7 signalling reliability and performance
   requirements for carrier grade networks, Network Operators might
   require that no single point of failure is present in the end-to-end
   network architecture between an SS7 node and an IP-based application.
   This can typically be achieved through the use of redundant SGPs or
   SGs, redundant hosts, and the provision of redundant QOS-bounded IP
   network paths for SCTP Associations between SCTP End Points."

Again all of the ingredients for a successful carrier grade deployment are
mentioned:
redundant SGPs or SGs, redundant hosts and provision of redundant
QOs-bounded IP network paths for SCTP Associations between SCTP End Points.

Basically, what we did in
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt
regrding redundancy issues was not to invent something conceptually new,
just to explain why/how of the M3UA redundancy architecture in detail,
compare it to MTP3 and give some suggestions how to practically achieve it
based on deployment experiences.

People are free to rely on multiple SGPs for network redundancy, but I doubt
they will get the failover quality of SCTP, i.e. failover with no loss and
no missequencing of messages.
>    (Fri, 24 Feb 2006 14:59:37)
> > Brian,
> >

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 14:27:24 -0700

Tolga,

The problem with relying on SCTP multihoming for network
redundancy is that it cuts down the usable bandwidth
because most SCTP implementations do not do CMT.  Multiple
single-homed SCTP associations provide redundancy while
efficiently using the available network bandwidth.  It
also provides for more controlled and cleaner network
design and administration for private (or virtual private)
networks.

Nevertheless, I said it was just an example.

Unlike you, (and your draft) I do not presume to tell others
how to go about setting up their network.  I belive that the
last paragraph that I cited was the most important: here it
is again:

It appears that you only want to consider the case where
there is full-mesh associations.  This is not the only (or
even a recommended) situtation.  No specific configuration
is recommended.  The protocol needs handle all situations,
whether you agree with their practicality or not.

And, I see no need to restrict the view of the protocol to
supporting only full-mesh at this late date.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 16:13:29 -0500

Brian,

I am not trying to impose some network architecture to people, but just to
show that given protocol mechanisms, using SCTP multihoming + multiple hosts
is the way to achieve carrier grade redundancy.

There could be of course exceptions, e.g. if somebody has a piece of
hardware which fails rare enough to satisfy the requirements, they may not
need host redundancy. Similarly if their network+NIC is very reliable they
may opt not to use multihoming.

   Tolga

> Sent: Friday, February 24, 2006 4:27 PM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 14:48:48 -0700

Tolga,

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 16:13:29)
> is the way to achieve carrier grade redundancy.

Sounds like you just made a recommendation to me.  I think all you are doing
is demonstrating how an non-coordinated AS state approach would simply provide
less redundancy and higher cost.

> may opt not to use multihoming.

How about if it is simply the fact that only one network exists between ASP1
and SGP2?  For example, ASP1 is in Mumbai and SGP2 is in Shanghai, and the
cost of providing a duplicate network between the two points is prohibitive
(or just not possible given current timelines).  Your non-coordinated state
approach will simply fail the entire system every time that a flakey router
in the Mumbai/Shanghai path causes an association to drop.  The coordinated
state approach will continue to process traffic.

Multihoming over a single network only provides NIC redundancy. (Ever had a
NIC fail?  I haven't in 30 years.)

SCTP Multihoming is not a panacea and is not even required of an SCTP
implementation.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 16:55:17 -0500

Brian,

> Sent: Friday, February 24, 2006 4:49 PM
> To: Tolga Asveren
> Cc: [email-masked]
>    (Fri, 24 Feb 2006 16:13:29)
> > Brian,
> >
[TOLGA]Several points:
a)Internal message routing between SGPs won't buy you lossless failover if
SCTP association is down (one will loose some of the sent but unacknowledged
messages)-but yes it is a good thing, when did I say that one shouldn't have
it?-
b)A properly designed network core has several mechanisms to deal with
failovers in a proper way. A few of the mechanisms described in 3.3 in
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt
can be used for this purpose, and *are* actually used.
c)If you can't provide a properly engineered IP network, you still can
deploy M3UA, you just need to keep the expectations about redundancy low,
and for certain cases that could be totally fine.
> NIC fail?  I haven't in 30 years.)
[TOLGA]Yes, I had.
> SCTP Multihoming is not a panacea and is not even required of an SCTP
[TOLGA]Yes, one can choose not to use multihoming as long as one knows what
it means from redundancy point of view.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 15:51:41 -0700

Tolga,

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 16:55:17)
> messages)-but yes it is a good thing, when did I say that one shouldn't have

Message loss is far better than complete service outage.

> can be used for this purpose, and *are* actually used.

Now you presume to tell others how to "properly" design their networks?

An operator does not necessarily (and does not usually) have design control
over all the networks that they use for transport, particularly in the Big I
to which M3UA is applicable.

> and for certain cases that could be totally fine.

With AS/ASP state coordination, an operator does not need to require that all
the networks that it traverses be engineered to your content, and will yet
experience higher redundancy at lower cost than your non-AS/ASP coordination
approach.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 17:39:53 -0500

Brian,

> Sent: Friday, February 24, 2006 5:52 PM
> To: Tolga Asveren
> Cc: [email-masked]
>    (Fri, 24 Feb 2006 16:55:17)
> > [TOLGA]Several points:
[TOLGA]Did I say otherwise? I don't understand how you started to speak
about this internal routing issue at all. We are discussing the benefits of
SCTP multihoming. Using SCTP multihoming does not mean that one shouldn't
have internal message routing, they are not mutually exclusive I repeat what
I said, internal routing is a nice thing to have.
> to which M3UA is applicable.
[TOLGA]I don't think people will deploy SIGTRAN in big-I Internet. That
people are not in control of the core network does not mean that they can
buy the QoS/VPN between two points they want.
> experience higher redundancy at lower cost than your non-AS/ASP
[TOLGA]I repeat again, internal routing is important but not enough for real
carrier grade deployment, but of course people are free to use the toplogy
they want.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 17:57:32 -0500

Ooopppsss typo:

[TOLGA]I don't think people will deploy SIGTRAN in big-I Internet. That
people are not in control of the core network does not mean that they can
buy the QoS/VPN between two points they want.                         ^^^^^
                                                                      can't

> Sent: Friday, February 24, 2006 5:40 PM
> To: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 16:25:50 -0700

Tolga,

AS/ASP state coordination allows provisions within the scope of
the M3UA protocol for increasing reliablity, rather than your
approach of attempting to place QoS requirements on the intervening
network, which is not only outside the scope of M3UA but is also
outside the scope of the SIGTRAN charter.

--brian

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 17:57:32)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 18:20:11 -0500

Brian,

> Sent: Friday, February 24, 2006 6:26 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Again several points:
a)Internal routing is a good thing to have -did I say this before? Hmm, let
me repeat it, because you snipped out that part-.
b)Internal routing can't provide the same lossless failover characteristics
of SCTP during failovers happening due to network/NIC errors, hence SCTP
multihoming is an important feature to provide carrier grade reliability.

But that is fine, to you your view and to me my view.

>
> --brian
>
> Tolga Asveren wrote:
>    (Fri, 24 Feb 2006 17:57:32)
> > Ooopppsss typo:
> >
>       ^^^^^

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Feb 2006 17:23:44 -0700

Tolga,

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 18:20:11)

> of SCTP during failovers happening due to network/NIC errors, ...

Yes it can.  See draft-bidulock-sigtran-corid-03.txt

Another thing that can be done within the application protocol that does
not place honerous requirements on the transport instead.

--brian

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