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

Stewart, Yakov and all,
I have started reading the draft, and it seems that it breaks quite a few common architectural assumptions.

The following text from Section 3.1 "Single-Segment PW" looks highly problematic to me:
<quote>
  At any given time, each CE sends traffic via only one AC and receives
   traffic via only one AC.  The two ACs MAY or MAY NOT be the same.
   The AC used to send traffic is determined by the CE, and MAY rely on
   an end-to-end OAM mechanism between the CEs.  The AC used for the CE
   to receive traffic is determined by the state of the network and the
   protection mechanism in use, as described later in this document.
<end quote>.

To the best of my order for the pair of interconnected CEs to be able to operate in this way each of them should treat the pair of ACs shown in Figure 1 as a single logical entity.
E.g., if we are speaking about Ethernet PWs, each CE could treat Ethernet links supporting these two ACs as a single Link Aggregation Group. However, the draft does not mention any such thing (or at least I did not find it).  

Do I miss something important here?

I also wonder whether, in the single segment PW scenario, the same level of protection could not be achieved with ICCP  (RFC 7275) running between each pair of PEs and, possibly with 4 (instead of 2) PWs.  For the reference, ICCP (or RFC 7275) is not mentioned in the draft, even if a possible alternative solution to some of the problems it solves. (

Stewart did not specify in his email which MPLS architecture principles he thinks are broken by this draft.

I think, however, that some PWE3 architectural principles are definitely are broken, and this includes:
- Bi-directional nature of the PW - it seems that the draft allows each a PW be Up in one direction and Down in the other one
- Lack of dependencies between the PSN tunnels and the PWs they carry. 
	* Consider the network diagram shown in Figure 5 in Section 4.1
	* The text suggests that the tunnel between PE1 and PE2 must recognize PE4 as the "protector" node for the PW it carries
	* What is supposed to happen if the tunnel between PE1 and PE2 carries, say, 10 PWs, each with its own backup PE PE4-1, ... PE4-10)? 
- Lack of dependencies between the mechanism used for the tunnel setup (LDP, RSVP-TE, manual configuration etc.) and the PWs this tunnel carries.
	* Is the protection model described in Section 4.1 compatible with Tunnel LSPs being set up by LDP? With, say, GRE tunnels carrying the PWs using MPLS-in-GRE?

Last but not least, I would like to understand better how the draft is protecting MS-PWs against S-PE failures. 
Specifically, I'd like to understand whether it is applicable to the case when each pair of T-PEs resides in its own AS, with two pairs of directly connected ASBRs between these two ASs acting as S-PEs.  There would be no need to set up any tunnel LSPs between each pair of S-PEs in this scenario.
I would appreciate an analysis of this scenario regarding ability to protect about the ASBR/S-PE failure. IMO it is a relevant scenario because MS-PWs are one of the methods to provide inter-AS services.

My 2c,
       Sasha 
Email: Alexander.Vainshtein@ecitele.com
Mobile: 054-9266302

> -----Original Message-----
> From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
> Sent: Tuesday, July 29, 2014 3:35 PM
> To: Yakov Rekhter; pwe3@ietf.org
> Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-
> protection-01
> 
> On 25/07/2014 16:24, Yakov Rekhter wrote:
> > Hi,
> >
> >> This email begins a second two week working group last call for
> >> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 .
> >>
> >> Please review the draft and post any comments to the PWE3 list.
> >>
> >> If you have read the draft, even if you don't have any comments, but
> >> would like to see the draft progressed,  please can you indicate this to the
> list.
> >>
> >> This working group last call will end on Friday August 8th, 2014.
> > I would like to see the draft progressed.
> >
> > Yakov.
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www.ietf.org/mailman/listinfo/pwe3
> >
> Yakov
> 
> Doesn't this draft implicitly make a number of extensions to the MPLS
> architecture?
> 
> Stewart
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3