RE: Query: IPSP-SE definition
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Soni, It is obvious that certain clarifications are necessary for the existing text in the document regarding IPSP, but still please see below for my 2 cents about how it is supposed to work. Thanks, Tolga > -----Original Message----- > From: [email protected] [mailto:[email protected]]On > Behalf Of Soni Goel > Sent: Tuesday, November 22, 2005 6:32 AM > To: [email protected] > Cc: [email protected] > Subject: RE: [Sigtran] Query: IPSP-SE definition > > > Hi, > > In one of the earlier mails , I saw the following configuration > being discussed. I have related query. > > It is an IPSP-IPSP Single Ended communication. We have AS1 served > by IPSP1. IPSP2 and IPSP3 are in the same > Application Server (AS2). Every IPSP is operating in Override > traffic mode, where IPSP1 and IPSP2 are > configured to be in the ASP-ACTIVE state and IPSP3 is acting as backup. > > ________ ________ ________ > | | | | | | > | AS1 | | AS2 | | AS2 | > | PC = X | | PC = Y | | PC = Y | > |________| |________| |________| > | | | > ___|____ ___|____ ___|____ > | | | | | | > | IPSP1 | | IPSP2 | | IPSP3 | > | IP@1 | | IP@2 | | IP@3 | > |Override| |Override| |Override| > |(Active)| |(Active)| |(Backup)| > |________| |________| |________| > | | | > |__________________|____________| > > As per the RFC - > "In the case of an Override mode AS, reception of an ASP Active > message at an SGP causes the (re)direction of all traffic for the > AS to the ASP that sent the ASP Active message. Any previously > active ASP in the AS is now considered to be in state > ASP-INACTIVE and SHOULD no longer receive traffic from the SGP > within the AS. The SGP or IPSP then MUST send a Notify message > ("Alternate ASP_Active") to the previously active ASP in the AS, > and SHOULD stop traffic to/from that ASP. "" > > In the following scenario, IPSP1 on receiving ASP Active Ack from > IPSP2, redirects all the traffic to IPSP2 and considers IPSP3 as > Inactive. Isn't this contradicting with the RFC paragraph (stated > above)? As per the RFC, the SGP or IPSP receiving ASP-Active > message redirects the traffic and sends NTFY(Alt ASP-Act), not > the IPSP receiving the ASP-Active Ack. > If this is true, then if IPSP1 needs to use Override mode towards > AS2 (consisting of IPSP2 and IPSP3), then ASP-Active messages > must be initiated by IPSP2 and/or IPSP3, not by IPSP1. [TOLGA]If you interprete the current text literally, I agree with you that is not very clear. OTOH, I don't see something conceptually wrong. The key point is that for SE-IPSP mode of operation AS defines traffic at both ends, it is not a cleint-server model like SGP/ASP communication. For that reason, ASPAC and ASPAC-ACK usually have the same semantics from SE-IPSP processing point of view. > > IPSP1 IPSP2 IPSP3 > | | | > |-------------------ASP Active----------------->| > |<----------------ASP Active Ack----------------| > | | | > |-------ASP Active------>| | > |<------ASP Active Ack---| | > | | | > |----------------NTFY(Alt ASP-Act)------------> | > | | | > > > Thanks, > Soni > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:[email protected]] > Sent: Monday, November 21, 2005 2:56 AM > To: Soni Goel > Cc: [email protected] > Subject: Re: [Sigtran] Query: IPSP-SE definition > > > Soni, > > Soni Goel wrote: (Mon, 21 Nov 2005 01:18:13) > > Hi, > > > > I have been following the IPSP-SE definition thread. As per the last > > mail from Ken the sigtran team will be working on draft(s) for SE-IPSP > > model and a SG-SG draft. > > > > In the meantime, is there any consensus reached regarding the IPSP-SE > > definition? > > No, I don't think that there was any concensus. > > > > > If yes, can you please let me know which of the following definitions > > are correct for IPSP-SE mode - > > The matter is rather moot because the TM in the ASP Active Ack is > just the same value that was present in the ASP Active. As it > stands, whichever view you take towards role modeling of IPSPs, > the side sending ASP Active can inform the other about its > intended traffic mode, but any traffic distribution method in the > other direction will have to be provisioned. > > It don't think that is such a great limitation: in a real world > engineered network I would expect that traffic mode (or > distribution method, if you prefer) would be provisioned on both sides. > > --brian > > > > > 1) In IPSP-SE model, the IPSP sending ASPAC acts as an ASP. The IPSP > > receiving ASPAC acts as an SGP. 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". > > > > OR, > > > > 2) SE-IPSP is an IPSP not an ASP and not an SGP. So, the traffic mode > > is required to be exchanged both ways. So if IPSP1 sends ASPAC message > > and IPSP2 replies with ASPAC-Ack message. IPSP2 can update IPSP1 about > > the traffic mode (in ASPAC-Ack message) to be used for message > > distribution towards IPSP2. This will enable both IPSP1 and IPSP2 to > > use same override/loadshare mode towards eahc other, OR, both IPSP1 > > and IPSP2 can use different modes. > > > > Thanks, > > Soni > > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > > > > > > _______________________________________________ > > Sigtran mailing list > > [email protected] https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > > > _______________________________________________ > Sigtran mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/sigtran >