RE: M3UA notify message

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Friday, February 24, 2006 4:49 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] 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.
[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.
>
> Multihoming over a single network only provides NIC redundancy.
> (Ever had a
> 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
> implementation.
[TOLGA]Yes, one can choose not to use multihoming as long as one knows what
it means from redundancy point of view.
>
> --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/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>