Subject: Re: [mpls-tp] R: operator commands and survivability in draft-Weingarten-mpls-tp-ring-protection

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 30 May 2010 15:22:01 +0200

Alessandro, hi

Sorry for the very long delay in replying to this - it got lost in all of the discussions that were going on at the time on the mailing list and then required consultation before giving a proper response (inline below).

BR,

yaacov

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext D'Alessandro Alessandro Gerardo
Sent: Friday, April 09, 2010 13:24
To: [email-masked]
Subject: [mpls-tp] R: operator commands and survivability in draft-Weingarten-mpls-tp-ring-protection

I renew my request to the authors and to the IETF community about some doubts I have about  the draft "draft-Weingarten-mpls-tp-ring-protection" :

1.	can operators count on "Operator commands" like FS (forced switch), MS (manual switch), LP(lockout of protection) for  both Wrapping and steering approaches? 

[yw>] Not sure what is meant by "can operators count on"!  If what is meant is there support for these - then the answer is a definitive "yes" - There is a basic question of how the operators want these commands to work - are they per LSP, per PST, or (for FS/MS) at the link level? If they are applied at the link level - then by issuing a FS/MS to any node on the ring the linear protection would send the appropriate notification to each of the PST (or SPME? Whatever they are called now) that would then switch all traffic to the appropriate protection path.  If they are being applied at the LSP/PST level, then it is simple linear protection application of the command.  

Regarding the LP - if this is applied to a particular LSP or PST then again it is simple application of the linear protection.  Not sure that I understand whether LP could be applied at the link level - what would it mean - that you are forcing all traffic to only use a single link? Or do you have to apply it to all of the links?

2.	does the proposed wrapping solution assure survivability in case of multiple arbitrary failures on a ring (e.g. survivability when any to any traffic relationships exist on the ring)? 

[yw>] Up front I should clarify that we cannot assure survivability for all cases (there will be some corner cases that may not be covered by any method).  The question that needs to be addressed here is  - how common are "multiple arbitrary failures on a ring"?  Second what is meant by "any to any traffic relationships" - is this mp2mp traffic?  If we are trying to address p2mp then the ROM-Wrapping method could be used to reach those egress points that are still accessible.  The points that are cutoff from the ingress node due to the multiple failures - are not reachable no matter what protection method is being used!  I might point out that in offline discussion you showed how draft-umansky could address certain instances of multiple failures - however, it should also be pointed out that this same method may cause an endless looping of messages - [assume the ring A-B-C-D-E-F-G-H-J-A and a working path from B->E  - if the link between C-D fails then (according to draft-umansky) Node C will wrap the traffic back around the ring using the "protection labels", and at Node D the traffic will be wrapped back to the working labels and arrive at Node E.  However if there is now a failure declared on the link F-G then the traffic will arrive at Node G on the protection labels and Node G will try to wrap the traffic back to the working labels (are they there? They might be there for some other path?) but if successful - then this traffic will continue to go back and forth between Nodes G & C constantly being wrapped back and forth!

3.	I guess it is possible to enhance the solution (respect to that one described in the draft that protect from a single link or single node failure) to face with multiple adjacent failures in a ring (e.g. two adjacent nodes). With that hypothesis in mind, has the wrapping approach a level of complexity that does not impact on the node scalability? 

[yw>] Again, are the operators really expecting many multiple failure scenarios?  This method of wrapping should be very scalable without any added complexity.

4.	focusing on the wrapping solution in the case of node failure, does the protection configuration require configuring which flows must be tunnelled towards the secondary node PST or it is not required?

[yw>] There is only the need to configure the association between the working PST and its "protection PST" which will be directed to the secondary node  - all LSPs that would normally be transmitted over the "working" will be redirected to the protection PST.  The protection PST is designed to protect against node failures.  When reaching the end of the protection PST - the traffic will be either wrapped back to the working path, or passed forward to the next node for treatment.   The choice will be based on the fact that at the end of the Protection PST the PST label will be popped and the underlying label can be examined - if this destination label is that of the next node (in the protection direction) then it will be forwarde to that node, in all other cases the traffic will be wrapped back onto the working PST.

Thanks in advance.

Best regards,

Alessandro

________________________________

Da: [email-masked] [mailto:[email-masked]] Per conto di D'Alessandro Alessandro Gerardo
Inviato: mercoledì 24 marzo 2010 22.13
A: [email-masked]
Oggetto: [mpls-tp] operator commands and survivability in draft-Weingarten-mpls-tp-ring-protection

I would ask some clarifications about the different ring protection mechanisms proposed in "draft-Weingarten-mpls-tp-ring-protection".

5.	can operators count on "Operator commands" like FS (forced switch), MS (manual switch), LP(lockout of protection) for  both Wrapping and steering approaches? 
6.	do the proposed solutions assure survivability in case of multiple arbitrary failures on a ring (e.g. survivability when any to any traffic relationships exist on the ring)? 
7.	I guess it is possible to enhance the solution (respect to that one described in the draft that protect from a single link or single node failure) to face with multiple adjacent failures in a ring (e.g. two adjacent nodes). With that hypothesis in mind, has the wrapping approach a level of complexity that does not impact on the node scalability? 

Thanks in advance.

Best regards,

Alessandro

------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

 Rispetta l'ambiente. Non stampare questa mail se non è necessario. 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.