RE: SE-IPSP definition
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Please see below for comments. > -----Original Message----- > From: Brian F. G. Bidulock [mailto:[email protected]] > Sent: Thursday, November 10, 2005 5:23 AM > To: Holland, Peter Michael (Peter) > Cc: 'Tolga Asveren'; [email protected] > Subject: Re: [Sigtran] SE-IPSP definition > > > Peter, > > Holland, Peter Michael (Peter) wrote: (Thu, 10 Nov > 2005 09:50:12) > > --X--snip--X-- > > > > So you agree that it does not work so well when both ASs have a > redundant > > architecture - loadshare or override? > > I don't understand why you refer to this as a pedantic > requirement - it is > > an architectural/implementation robustness requirement in some > situations. > > > --X--snip--X-- > > It is pedantic because an IPSP does not need an ASP Traffic Mode to be > redundant. When acting like an SGP, the peer IPSP can distribute > traffic in accordance with the way that an ASP distributes messages to > the SGP that make up an SG. The SE-IPSP acting in SGP mode does not > require an "ASP Traffic Mode". > > Traffic Mode (the parameter) is an ASP concept. Is is only useful to an > SE-IPSP in so much as the SE-IPSP is behaving like an ASP. In SE mode, > it was never intended that both sides behave like an ASP at the same > time. That is DE mode. [TOLGA]SE-IPSP is an IPSP not an ASP not an SGP. For certain message transactions, it follows the same message sequence but conceptually it is not equal to ASP not to SGP. So, I 100% agree with Peter, traffic mode is necessary bothways for SE-IPSP case. Traffic mode is an attribute associated with application logic and for IPSP case, there is application logic present at both ends. > > --brian > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ >