Subject: RE: [Sigtran] M3UA notify message

From: "Haresign Lincoln" <[email-masked]>
Date: Fri, 24 Feb 2006 09:52:19 -0500

Tolga,

I agree with you that you would use multihoming in this case.  My guess
is that Brian was trying to demonstrate a point relating to M3UA and the
issues under discussion.

Regards,
Lincoln 

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 9:24 AM
To: [email-masked]
Subject: RE: [Sigtran] M3UA notify message

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, February 24, 2006 2:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M3UA notify message
>
>
> prabind.chaubey,
>
> I think that you understand the situation well now.
>
> Because AS state depends upon ASP state, it is really not possible to 
> coordinate AS state across multiple SGP without also coordinating ASP 
> state.  That is why I feel that Greg stated the situation well in 
> 1.4.1 when he said:
>
>   "Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
>    remote AS/ASP states of each SGP SHOULD be coordinated across all
the
>    SGPs.  Rerouting of traffic between the SGPs MAY also be
supported."
>
> Also note that we never required that a full-mesh of SCTP associations

> be formed between ASPs and SGPs.  And, certainly, as you illustrate 
> below, the failure of an association (or two) can reduce a full-mesh 
> to a sparse set of SCTP associations anyway.  A full mesh would likely

> only be for network redundancy.  If I have 2 ASPs, 2 SGPs and 2 
> networks, the most efficient arrangement from a performance/failure 
> perspective would be as follows:
>
>   ASP1  -------network A------- SGP1
>         \______network B______/
>          ______network B_____/\
>         /                      \
>   ASP2  -------network A------- SGP2
[TOLGA]No, this is not really how it should be done -it is not wrong,
but one should be ready to face consequences with such a setup-. I would
expect both networks to be used between each peer with SCTP multihoming.
We discussed this several times  that SCTP multihoming with multiple
networks is practically necessary for a carrier grade environment.
>
> In that way if only network A fails, each ASP is still connected to a 
> different SGP (for performance), and the same is true if only network 
> B fails.  If network B fails, the situation degrades to
>
>   ASP1  -------network A------- SGP1
>
>
>   ASP2  -------network A------- SGP2
[TOLGA]If SCTP multihoming is used properly, there won't be any
isolation because each STP association would utilize both networkA and
networkB.
>
> The ability of the system to operate, should not be adversely affected

> by the loss off network B.  If the SG does not coordinate AS/ASP 
> state, in scenarios like the 2+k scenario you detail, the system will 
> not function to the same degree as that where AS/ASP state is 
> coordinated.  Good reason for the SHOULD.
[TOLGA]If SCTP multihoming is used utilizing both networks, ability of
the system is not affected at all when networkB fails.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran
--------------------------------------------------------------------
This email message has been scanned by Comverse mail security system

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 Feb 2006 09:40:40 -0500

Lincoln,

Yes, I figured that, but the case is still misleading. It tries to utilize
global-AS view as a tool for redundancy, where actually SCTP-multihoming
needs to be utilized. I don't think such a replacement is recommended,
considering that SCTP will provide failover without message loss and
missequencing.

    Thanks
    Tolga

> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Friday, February 24, 2006 9:52 AM
> To: Tolga Asveren; [email-masked]