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

[Alexander Vainshtein <[e-mail]>]

Yimin hi!

Please see a couple of comments inline below (marked [[Sasha]].

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

Hi Sasha,

All ACs and PWs in this draft are active at individual level. One set of AC-PW-AC is used as backup to protect the other set of AC-PW-AC (i.e. primary).

I think we both agree that CE behavior is out of the scope of PWE3. 

[[Sasha]] Yes - provided that PWE3 matches reasonable CE expectations. If it is not so, it becomes very much in scope IMO.

If you want to run L3 between CEs, you could bundle the two ACs on CE as a single logical L3 interface. I'm sure there are other approaches depending on the type of CE. But again, this is out scope of PWE3.

[[Sasha]] Well, not really IMO. E.g., Section 7.2 of RFC 7225 specifically defines a PWE3 solution for PW redundancy with multi-Chassis LAG. This solution addresses the case when a dual-homed CE perceives a pair of Ethernet links between itself and a pair of redundant PEs as a single Link Aggregation Group, and effectively uses LACP as the dual-homing protocol. I'd say that if you decide that CE should use some standard (or widely deployed) mechanism between itself and the PEs in order for PWE3 to provide a meaningful service, PWE3 has both to specify its expectations regarding the CE behavior and the methods it uses to accommodate this behavior. 
An example that looks highly relevant to me with regard to your draft is like following:

The draft explicitly differentiates between "ingress" and "egress" AC failures and states that "Today, fast protection against ingress AC failure and ingress (T-)PE  failure is achievable by using a multi-homed CE and redundant PWs.". Suppose that CE and PE employ some native mechanism (out of scope of PWE3, of course) that would revert any unidirectional AC failure to a bi-directional one in a very fast manner. (One example that comes to mind is the LF/RF exchange mechanism oft 10-Gigabit Ethernet.) Would such a mechanism eliminate the need  to protect against egress AC failures which seems to be one of the major drives for the draft?

The "fast protection" refers to the ability to locally detect failure, restore traffic, and reduce loss. CEs and PEs may go through any negotiation or coordination to move traffic from the repaired PW to anther PW, at any pace. Before that happens, traffic has already been repaired by this mechanism.


Thanks,

/Yimin



-----Original Message-----
From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Tuesday, August 05, 2014 1:13 AM
To: Yimin Shen
Cc: [e-mail]; Yakov Rekhter; [e-mail]
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Yimin hi,
I apologize for missing your response when it has been sent.

I will try to address some of your comments without yet one more level of in-lining:-).

[Yimin] This draft assumes active-active PWs and bidirectional ACs.
[Sasha] It would be nice if this were explicitly stated in the draft.

[Yimin] I think you are talking about how to run Layer 3 between CEs with an overlay model, which I don't think is in scope of PWE3 architecture [Sasha] To the best of my understanding PWE3 is about an emulation of a native service. It does not have to be perfect, but limitations are supposed to be explicitly presented in Applicability Statements.  On the practical level, if a PW mechanism is not good enough to carry L3 traffic between a pair of CEs, what is it good for?
And, last but not least, if CE1 and CE2 in my example were L2 switches running some flavor of STP, the situation would be no less disruptive.

[Yimin] In case of egress AC failure, CE2 will detect the failure and start to send traffic over PW2 (i.e. the backup PW).
[Sasha] This is an assumption about CE2 which is definitely out of scope of the PWE3 architecture. Actually what you say is that CE2 should treat its failure to receive traffic over an AC as a bi-directional AC failure.
[Yimin] CE1 should also start to send traffic over the backup PW2. This may be triggered by many events, e.g. [1] PE1's notification to CE1 based on the PW status you mentioned above (but it is not mandatory); [Sasha] This is possible of course, but, as you've said, not mandatory [Yimin] or [2] CE1 receiving traffic from PE3.
[Sasha] But you've said that ACs are active-active. So why receiving something from PE3 would be of any interest?
And of course, there is a case when only CE2 is dual-homed but CE1  is not... Is the draft relevant in this scenario?
[Yimin] In any case, it may take some time for CE1 to do so. Before this happens on CE1, the traffic is still going over PW1 (primary PW) which is being locally repaired by PE2.
[Sasha] I'd say that the draft relies on some "dual-homing protocol" between a dual-homed CE and its PEs to provide for a bi-directional switch, and that such a switch could take some time. I am not sure this counts for "fast protection".

Regards,
Sasha



________________________________________
From: Yimin Shen <[e-mail]>
Sent: Thursday, July 31, 2014 2:22 AM
To: Alexander Vainshtein
Cc: [e-mail]; Yakov Rekhter; [e-mail]
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Hi Sasha,

Thanks again for your comments. Please see inline...


Thanks,

/Yimin



-----Original Message-----
From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Wednesday, July 30, 2014 4:08 AM
To: Yimin Shen
Cc: [e-mail]; Yakov Rekhter; [e-mail]
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Yimin hi,
Lots of thanks for a prompt response.

Unfortunately, from my point of view, the issues I've raised still remain unresolved. Please see additional questions inline below.

Regards,
       Sasha
Email: [e-mail]
Mobile: [phone]

> -----Original Message-----
> From: Yimin Shen [mailto:[e-mail]]
> Sent: Tuesday, July 29, 2014 7:56 PM
> To: Alexander Vainshtein; [e-mail]; Yakov Rekhter;
> [e-mail]
> Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-
> protection-01
>
> Hi Sasha,
>
> Thanks very much for the review and comments. Please see my responses
> inline. Hope they are helpful.
>
>
> Thanks,
>
> /Yimin
>
>
>
> -----Original Message-----
> From: pwe3 [mailto:[e-mail]] On Behalf Of Alexander
> Vainshtein
> Sent: Tuesday, July 29, 2014 10:08 AM
> To: [e-mail]; Yakov Rekhter; [e-mail]
> Subject: 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.
>
> [yshen] This draft is fully based on the PWE3 architecture and the
> MS-PW architecture.
>
> 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?
>
> [yshen] It is a logical view that the CE is dual-home to 2 PEs over 2
> distinct ACs. AC is a concept well defined in RFC 3985. In terms of
> the actual PE-CE connection in the case of Ethernet, the CE could have
> 2 distinct Ethernet links or 2 VLANs over a single LAG.
>
[[Sasha]] If I read your response correctly, each dual-homed CE treats each if its two ACs as an individual entity.
I see this is as highly problematic. E.g., consider the case when CE1 and CE2 are two CE routers running some link-state routing protocol between them.
-  In the normal situation, CE1 probably would see its two ACs as two parallel bi-directional links.
- With PW redundancy, one of these links (one that corresponds to the current Active PW) would be Up and the other one - Down
- With your proposal, the typical link-state routing protocol between CE1 and CE2 would not be able to form any adjacencies across any of these links, because this process requires bi-directional link connectivity; so regardless of whatever happens in the PW domain CE1 and CE2 would consider each other as unreachable across this domain.
Did I miss something? (I intentionally leave aside protocols like OLSR that can handle unidirectional links).

[yshen] I'm lost in the last 2 bullets. This draft assumes active-active PWs and bidirectional ACs. I think you are talking about how to run Layer 3 between CEs with an overlay model, which I don't think is in scope of PWE3 architecture.






> 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. (
>
> [yshen] Thanks for pointing out ICCP. We will mention it in the next revision.
> In this draft we broadly refer to such kind of mechanism as "control
> plane repair". The purpose of this draft is to locally repair traffic
> at the failure point, in order to reduce traffic loss before ICCP or
> other control plane repair mechanism kicks in.

[[Sasha]] I am not sure ICCP in this case would mean slow protection. Its function here would be just to synchronize the state of PWs between PE1 and PE3/PE2 and PE4, and this can be reasonably fast IMO. The Protection State Coordination (PSC) protocol in RFC 6378 looks like an analog (with some stretch of course), and it is supposed to provide pretty fast protection switching.

[yshen] The draft doesn't comment specifically on ICCP performance. Generally speaking, local repair mechanism tends to have the least overhead when restoring traffic. This is because both failure detection and traffic restoration are done right in the dataplane. It doesn't rely on dataplane to control plane notification (for failure event) or control plane protocol. For this exact reason there have been various IP/MPLS fast-reroute mechanisms defined by IETF. Of course, in a given scenario where the delay in global repair or control plane repair is tolerable for users, they don't have to use local repair. Local repair is for the case where it is desirable to reduce traffic loss even further. Note that local repair is a temporary repair, and it doesn't prevent global repair or control plane repair to perform a permanent repair. I believe the draft has specifically mentioned this.





>
> 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
>
> [yshen] No, the draft does not allow that. It only says that we can
> send traffic of one direction over one PW, while sending traffic of
> the opposite direction over another PW (i.e. backup PW). Both PWs should be up bidirectionally.
>
>
[[Sasha]] Sorry but I do not understand that. The draft discusses something like  the "egress AC failure". If, say. PE1 detects that, I expect it would send a PW Status with "PW not Forwarding" and "Local AC Transmit Fault" bits set to PE2. Would this not mean that the PW between PE1 and PE2 is Down?

[yshen] In case of egress AC failure, CE2 will detect the failure and start to send traffic over PW2 (i.e. the backup PW). CE1 should also start to send traffic over the backup PW2. This may be triggered by many events, e.g. [1] PE1's notification to CE1 based on the PW status you mentioned above (but it is not mandatory); or [2] CE1 receiving traffic from PE3. In any case, it may take some time for CE1 to do so. Before this happens on CE1, the traffic is still going over PW1 (primary PW) which is being locally repaired by PE2.






> - 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)?
>
> [yshen] In your example, the 10 PWs are protected by 10 different
> protectors. In this case, you would need 10 different tunnels,
> destined to 10 different context IDs (one context ID per <PE2,
> PE4-x>). If multiple PWs are protected by the same protector, they can be carried by the same tunnel.
>
[[Sasha]] This looks like a non-scalable solution to me.

[yshen] I'm not sure there is any scalability issue here. We basically need one tunnel per context ID, i.e. per <primary PE, protector>. In reality, the number of <primary PE, protector> should not be high. The draft also specifies the centralized model for reducing the number of context IDs.





>
> - 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?
>
> [yshen] Yes, it is compatible. The draft is generic on transport
> layer, and it allows tunnels to be LDP, RSVP-TE, GRE, etc. These
> protocols already provide sufficient machineries for setting up transport tunnels and bypass tunnels.
> Therefore, the draft doesn't require new extension to these LSP
> signaling protocols.
>
[[Sasha]] Sorry but this does not match your response to my previous question/issue where you have explained that you effectively need a tunnel per PW between PE1 and PE2. RSVP-TE can provide that; but how is LDP supposed to do that?

[yshen] Again, a tunnel can carry multiple PWs, if these PWs are protected by the same protector. You could use 10 different protectors to protect 10 PWs, but in reality when SP design their network, they should ask why they have to do so. Regarding LDP, it is one FEC per context ID, and nothing special.




> 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.
>
> [yshen] The MS-PW topology in this draft is based on the Figure-4 of
> RFC 5659, which is slightly different than the scenario you mentioned above.
>
[[Sasha]] Figure 4 in RFC 5659 does not say anything about inter-AS.
>
> However, the mechanism in this draft does apply to this scenario as
> well. It should work equally if S-PEs are one-hop or multi-hops away
> from each other. Please see the picture below. In this case, SPE1 ~ SPE4 are ASBRs.
> When SPE4 detects the failure of SPE3, it will do a local repair and
> redirect PW traffic to SPE4 which is the protector. The bypass between
> SPE1 and SPE4 may be a one-hop tunnel or a multi-hop tunnel, depending
> on the actual topology between the 2 AS'.
 >
[[Sasha]] This approach can work if SPE1 is directly connected to SPE4 because in this case there would be no need for a tunnel LSP between them.
I do not see a simple way to set up an LSP between SPE1 (in AS-1) and SPE4(in AS-2) if such connectivity is not present; could you possibly expand on how this is supposed to happen?

[yshen] Sasha, if you don't have a bypass tunnel (due to specific topology or policy or whatever), you won't get any IP/MPLS fast-reroute mechanism to work :) However it doesn't mean the mechanism is broken. In your case, I don't see any technique issue why you cannot set up a inter-AS bypass from SPE1-SPE2-SPE4.



>
 >  In any case, SPE4 will send PW traffic over a
> tunnel to TPE4.
>
>                   |<--------------- PW1 ----------->|
>
>              - TPE1 -------- SPE1 - SPE3 --------- TPE2 -
>             /                PLR \                       \
>            /                      \                       \
>         CE1                  bypass\                        CE2
>            \                        \                     /
>             \                        \                   /
>              - TPE3 -------- SPE2 - SPE4 --------- TPE4 -
>                                   protector
>
>                   |<--------------- PW2 ----------->|
>
> My 2c,
>        Sasha
> Email: [e-mail]
> Mobile: [phone]
>
> > -----Original Message-----
> > From: pwe3 [mailto:[e-mail]] On Behalf Of Stewart
> > Bryant
> > Sent: Tuesday, July 29, 2014 3:35 PM
> > To: Yakov Rekhter; [e-mail]
> > 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
> > > [e-mail]
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3