Re: [PWE3] PWE3 WG last call for draft-ietf-pwe3-iccp-stp-01

[Alexander Vainshtein <[e-mail]>]

Andy and all,
I’ve read the draft and I do not think that in its present form it is ready for publication.

To the best of my understanding, the draft deals with a well-known problem when a native bridged network (usually an access segment) :

·         Is dual-homed to an IP/MPLS network

·         Uses some services in this network as “virtual links” for its own redundancy

·         Uses STP for loop-breaking (including loops thru the services running over the IP/MPLS core).

This problem admits a well-known and, AFAIK, widely deployed solution based on BPDU tuinneling and TCN snooping.

The draft describes a solution based on BPDU tunneling for one very special case, namely when the service provided by the IP/MPLS core is only used to provide resilience for the geographically dispersed native bridged network – if you look at the diagram in Figure 2.1, it only contains two PEs to which the native L2 service is dual-homed. This solution is described in some detail, and some issues found with it.

My first concern is with the description of this solution and the issues found with it:

1.       The draft does not explain that, in addition to tunneling BPDUs, PE1 and PE2 also tunnel customer traffic (but this is easy to guess)

2.       In the topology shown in the diagram, PE1 and PE2 do not have to take any forwarding decisions based on MAC addresses in the traffic they tunnel:

a.       PE1 tunnels all the frames received from port 4 (including BPDUs) to PE2 via the tunnel (PW?) and transmits all the frames received from this tunnel via port 4

b.      PE2 tunnels all the frames received from port 5 (including BPDUs) to PE1 via the tunnel (PW?) and transmits all the frames received from this tunnel via port 5

3.       As a consequence:

a.       PE1 and PE2 do not have to respond to any changes in the topology of the native bridging network (including the virtual link they provide between CE1 and CE2).  In particular, there is no need to snoop TCN messages. Such snooping may be required in a more complicated network, but the draft does not include the relevant examples.

b.      Slow STP convergence in the case when physicla link fialure is detected is well-known and common to many scenarios. E.g., if the PE1 and PE2 would use Ethernet over SONET, failure of link between CE2 and PE2 would not be, in most cases,  detected by CE1. One of the ways to solve this problem could be monitoing of a “virtual” link between CE1 and CE2 using Ethernet Link OAM or Ethernet CFM.

4.       I have failed to understand the linkage between single-segment PWs (to which, according to the draft, RFC 7023 is scoped – and I am not sure this is indeed so!) and configurations when a full mesh of PWs is required because an STP network is connected to more than 2 PEs.  But there are well-known solutions and deployed  for these scenarios as well.

The dratf then proceeds with proposed extensions to ICCP in Section 3 that presumably should solve the same problem.
But it does not contain any “Theory of operation” section that explains how these extesnsions should be used in ordder to provide a solution.

An ultra-brief text in the Introduction (“the RG members pretend to be a single root bridge to participate the operations of the STP. STP relevant information need be exchanged and synchronized among the RG members”) is not, IMHO and FWIW, enough.  The draft does not even state explicitly and in a normative way, that exactly one of the PEs MUST run STP (even if this can be guessed). Neitther it is clear what should happen when STP is migrated from one PE to another. Is any form of state synchronization required? Is it achieved via ICCP?



The draft also does not provide any comparison between the “private” solution and the proposed one – neither for the trivial topology that is shown in the network diagrams, nor for more common ropologies (e.g., with two native L2 domains being dual-homed to two  different pairs of PEs?).



Please note that my concerns with the draft are mainly about its readability. IMO until the missing descriptions are provided, it is very difficult to discuss techincal merits  of the proposal.


Hopefully these notes will be useful.

My 2c,,
       Sasha
Email: [e-mail]
Mobile: [phone]

From: pwe3 [mailto:[e-mail]] On Behalf Of Andrew G. Malis
Sent: Tuesday, May 13, 2014 4:40 PM
To: [e-mail]
Subject: Re: [PWE3] PWE3 WG last call for draft-ietf-pwe3-iccp-stp-01

PWE3ers,

By the way, this was a solicitation of comments on the draft. Is there anyone out there that has read it and feels that it's ready for publication?

Thanks,
Andy

On Sun, May 11, 2014 at 5:36 PM, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> wrote:
Although the last call period for this draft has ended, we are still waiting for one of the authors to answer the IPR poll.

It would also be nice to have responses from the WG regarding the draft, it would be good to see some evidence that people have read it and feel it is ready for publication. To date, I've not seen any responses at all.

Thanks,
Andy

On Thu, Apr 24, 2014 at 11:26 PM, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> wrote:
This email begins a two week working group last call for http://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-01 .

Please review the draft and post any comments to the PWE3 list.

This working group last call will end on Friday May 9, 2014.

Thanks,
Andy and Matthew