Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

[Alexander Vainshtein <[e-mail]>]

Yimin, Stewart and all,
I have serious doubts regarding the possibility to combine the mechanism defined in this draft with LDP-instantiated LSPs as tunnels for PWs.

Please consider the following use case:

- The PSN is an MPLS network with a full mesh of tunnel LSPs between all the PE that is instantiated between the PEs
- ECMP exists in this network so that actually there are several equal cost LSPs between PE1 and PE2, possibly with different penultimate hops, say, P1 and P2
- The user sets up a PW between PE1 and PE2 and defines PE3 as the "protector PE" for PE2 for this PW with some CE dual-homed to PE2 and PE3. 
 - The user defines the PW in question as a "fat"(a.k.a. flow-aware) PW. As a consequence some flows in this PW pass thru P1 and some other flows  - thru P2. However,   initially all these flows reach the CE via its link to PE2
- The link between P1 and PE2 fails. As a consequence the flows within the fat PW passing thru this link are redirected redirected to PE2. At the same time, the link between P2 and PE2 remains intact, so that the flows passing thru this link are not redirected
- The result is that some of the flows in the PW in question now reach the CE via its link to PE2 and some - via its link to PE3.  Since you've explained (see http://www.ietf.org/mail-archive/web/pwe3/current/msg13879.html) that "CE is dual-home to 2 PEs over 2 distinct ACs", the results could be discouraging: e.g., consider the case when you are running an fat Ethernet PW between two IP-callable devices, and, as the result of the split, IP traffic reaches the CE via one AC but ARP - via the other AC.

I also have doubts regarding ability of LDP to take into account the relationship between the initial destination PE and the protector PE. To the best of my understanding, the only thing LDP would recognize when setting up tunnel LSP is the ""Context ID IP address" - presumably an additional loopback address of the original destination PE. I do not see how, without suitable extensions it could identify Protector PE. 

I also suspect that LDP could recognize multiple Context ID addresses as belonging to the same PE router and as a consequence merge LSPs that use this IP address as a /32 IPv4 prefix FEC. If this happens, it would break the entire mechanism in the scenarios when the same destination PE participates in multiple contexts - quite a reasonable situation in the case of MS-PWs with S-PE protection IMO, but also possible in the case of a T-PE that use different Protectors for different PWs.

 Did I miss something substantial? 

Regards, 
Sasha
________________________________________
From: Yimin Shen <[e-mail]>
Sent: Monday, August 4, 2014 8:46 PM
To: [e-mail]; Alexander Vainshtein
Cc: Yakov Rekhter; [e-mail]
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Hi Stewart,

Yes, it works with both LDP and RSVP-TE (or other signaling protocols). This is based on the PWE3 architecture where PWE3 layer and PSN layer are decoupled. If PSN is MPLS, all we need is an MPLS tunnel to the primary (or protected) PE, and an MPLS bypass tunnel from the PLR to the protector. The two tunnels may be LDP or RSVP-TE (or another protocol). The context ID defined in this draft can be used to facilitate the setup of these tunnels.


Thanks,

/Yimin



-----Original Message-----
From: Stewart Bryant [mailto:[e-mail]]
Sent: Monday, August 04, 2014 1:32 PM
To: Yimin Shen; Alexander Vainshtein
Cc: Yakov Rekhter; [e-mail]
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Yimin

A question before I reply in detail

Does this work over both an LDP signaled MPLS layer and an RSVP-TE signaled MPLS layer?

Stewart