Subject: RE: [Sigtran] M2PA Comment: Multi-homing

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 19 Jun 2002 10:08:33 +0200

Hi,

Although the well-known MTP3 procedures such as changeover, changeback, forced and controlled rerouting can give a certain degree of reliability I would support to include the multihoming host. Upon the failure of a remote NIC, it will be a faster procedure to change the remote IP address inside the association that triggering the MTP3 procedures. Multihoming hosts would certainly improve the performance in those cases. It would be then a desirable feature IMHO.

Cheers // Javier.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 18, 2002 10:06 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M2PA Comment: Multi-homing
> 
> 
> 
> Folks,
> 
> My recollection regarding this subject is that multi-homing is not
> necessary for m2pa because fault tolerance would be obtained 
> through the
> use of changeover and changeback at the MTP3 level.  However, I am not
> aware of any technical reason why multi-homing cannot be 
> supported.  So I
> am not opposed to changes indicating m2pa use of multi-homing 
> provided it
> is optional.
> 
> Regards
> Ray
> 
> 
> 
> 
>                                                               
>                                
>                     amish.chana@or                            
>                                
>                     ange.co.uk            To:     
> [email-masked]                  
>                                           cc:     
> [email-masked], (bcc: Ray P.             
>                     06/18/02 10:07        Singh/Telcordia)    
>                                
>                     AM                    Subject:     Re: 
> [Sigtran] M2PA Comment:           
>                                           Multi-homing        
>                                
>                                                               
>                                
> 
> 
> 
> 
> 
> 
> 
> Technically, I don't see any reason why multi-homing cannot 
> be used and I
> argree
> with you.
> Maybe this is more of an editorial comment, in that the draft 
> should better
> reflect the multi-homed nature of endpoints.
> 
> A.
> 
> 
> 
> 
> 
> 
> [email-masked] on 18/06/2002 14:55:08
> 
> 
> 
> 
> To:   Amish CHANA/EN/HTLUK@HTLUK
> cc:   [email-masked]
> 
> 
> Subject:  Re: [Sigtran] M2PA Comment: Multi-homing
> 
> 
> 
> 
> Hello Amish,
> 
> The M2PA draft does not prohibit multihomed associations, 
> therefore they
> can be used.
> The 'claim' I mentioned has to do with prior discussions. I 
> was not quoting
> from the draft.
> 
> Regards,
> 
> Jeff
> 
> 
> 
> 
> 
> **************************************************************
> *****************
> 
> 
> 
> Important.
> Confidentiality: This communication is intended for the 
> above-named person
> and
> may be confidential and/or legally privileged. Any opinions 
> expressed in
> this
> communication are not necessarily those of the company. If it 
> has come to
> you
> in error you must take no action based on it, nor must you 
> copy or show it
> to
> anyone; please delete/destroy and inform the sender immediately.
> 
> Monitoring/Viruses
> Orange may monitor all incoming and outgoing emails in line 
> with current
> legislation.  Although we have taken steps to ensure that 
> this email and
> attachments are free from any virus, we advise that in 
> keeping with good
> computing practice the recipient should ensure they are actually virus
> free.
> 
> Orange PCS Limited is a subsidiary of Orange SA and is registered in
> England No
> 2178917, with its address at St James Court, Great Park Road, 
> Almondsbury
> Park,
> Bradley Stoke, Bristol BS32 4QJ.
> **************************************************************
> *****************
> 
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> 
> 
> 
> 
> 
> 
> **************************************************************
> *****************
> 
> 
> Important.
> Confidentiality: This communication is intended for the 
> above-named person
> and
> may be confidential and/or legally privileged. Any opinions 
> expressed in
> this
> communication are not necessarily those of the company. If it 
> has come to
> you
> in error you must take no action based on it, nor must you 
> copy or show it
> to
> anyone; please delete/destroy and inform the sender immediately.
> 
> Monitoring/Viruses
> Orange may monitor all incoming and outgoing emails in line 
> with current
> legislation.  Although we have taken steps to ensure that 
> this email and
> attachments are free from any virus, we advise that in 
> keeping with good
> computing practice the recipient should ensure they are actually virus
> free.
> 
> Orange PCS Limited is a subsidiary of Orange SA and is registered in
> England No
> 2178917, with its address at St James Court, Great Park Road, 
> Almondsbury
> Park,
> Bradley Stoke, Bristol BS32 4QJ.
> **************************************************************
> *****************
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> 
> 
> 
> 
> 
> 
> **************************************************************
> *****************
> 
> Important.
> Confidentiality: This communication is intended for the 
> above-named person
> and
> may be confidential and/or legally privileged. Any opinions 
> expressed in
> this
> communication are not necessarily those of the company. If it 
> has come to
> you
> in error you must take no action based on it, nor must you 
> copy or show it
> to
> anyone; please delete/destroy and inform the sender immediately.
> 
> Monitoring/Viruses
> Orange may monitor all incoming and outgoing emails in line 
> with current
> legislation.  Although we have taken steps to ensure that 
> this email and
> attachments are free from any virus, we advise that in 
> keeping with good
> computing practice the recipient should ensure they are actually virus
> free.
> 
> Orange PCS Limited is a subsidiary of Orange SA and is registered in
> England No
> 2178917, with its address at St James Court, Great Park Road, 
> Almondsbury
> Park,
> Bradley Stoke, Bristol BS32 4QJ.
> **************************************************************
> *****************
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Jun 2002 08:44:06 -0500

Javier,

I highly doubt that SCTP with an Rto.Min of 1 second will have anywhere
near the performance of MTP3 in detecting even remote NIC failures.  MTP3
will fail the link in 1 second whereas SCTP will only start its first
retransmission in 1 second with an Rto.Min of 1 second in the case of a
remote NIC failure.  Any use of SCTP multihoming for M2PA is marginal at
best, given the current recommended and required protocol parameters for SCTP.
IMO it would be foolish to accent SCTP mutlihoming in the draft as it is
rather useless for M2PA.  Because it is not forbidden, however, it is
permitted.  We have arlready exchanged more text that the subject deserves.

--brian

Javier Pastor-Balbas (ECE) wrote:                          (Wed, 19 Jun 2002 10:08:33)
> Hi,
> 
> Although the well-known MTP3 procedures such as changeover, changeback,
> forced and controlled rerouting can give a certain degree of reliability I
> would support to include the multihoming host. Upon the failure of a remote
> NIC, it will be a faster procedure to change the remote IP address inside
> the association that triggering the MTP3 procedures. Multihoming hosts would
> certainly improve the performance in those cases. It would be then a
> desirable feature IMHO.
> 
> Cheers // Javier.
> 

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