Re: M3UA notify message

Tolga,

Tolga Asveren wrote:                                                 (Fri, 24 Feb 2006 16:13:29)
> 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.

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.

> 
> 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.

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

> 
>    Tolga
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Friday, February 24, 2006 4:27 PM
> > To: Tolga Asveren
> > Cc: [email protected]
> > Subject: Re: [Sigtran] M3UA notify message
> >
> >
> > 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:
> >
> >    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.
> >
> > 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 protected]
> > http://www.openss7.org/
> >
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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