Subject: [Sigtran] Query: IPSP-SE definition

From: "Soni Goel" <[email-masked]>
Date: Mon, 21 Nov 2005 01:18:13 -0800

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? 

If yes, can you please let me know which of the following definitions are correct for IPSP-SE mode -

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-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 21 Nov 2005 03:56:05 -0700

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

No, I don't think that there was any concensus.

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

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