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

[Alexander Vainshtein <[e-mail]>]

Hi Mingui,
Please see specific  comments to your responses inline below prefixed with [[Sasha]].

But, as an introduction to these comments, I'd like to explain that, from my point of view, a Standard Track RFC (which your draft becomes if/when it is published) must provide sufficient information for a *reasonably qualified* engineer to build an interoperable implementation based on what is written in the draft and in its Normative references. AFAIK, this is view is quite common in the IETF. 

One could, of course, argue about who should be considered a "reasonably qualified engineer". But, as I see it, the draft, in its present form, falls short of this basic requirement.  Please note that this does not say anything about actual solution, only about your description of this solution in the draft.

Hopefully these notes will be useful.

Regards,
     Sasha
________________________________________
From: Mingui Zhang <[e-mail]>
Sent: Friday, May 16, 2014 4:30 AM
To: Alexander Vainshtein; Andrew G. Malis
Cc: [e-mail]; Wenhuafeng; [e-mail]
Subject: RE: [PWE3] PWE3 WG last call for draft-ietf-pwe3-iccp-stp-01

Hi Sasha,

Thanks for your comments. Please find my respond inline below.

Mingui

>-----Original Message-----
>From: Alexander Vainshtein [mailto:[e-mail]]
>Sent: Tuesday, May 13, 2014 11:33 PM
>To: Andrew G. Malis
>Cc: [e-mail]; Mingui Zhang; Wenhuafeng; [e-mail]
>Subject: RE: [PWE3] PWE3 WG last call for draft-ietf-pwe3-iccp-stp-01
>
>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.

MINGUI> As far as we know, there is a few proprietary BPDU tunneling implementations around. But, it is not yet widely deployed. We included this solution to reflect the consensus of the WG. It helped us to grasp the ICCP-STP proposal. However, this document is not intended to invalidate that proprietary choice. As a vendor to provide products to various carriers, sometimes, a new solution is proposed as an alternative.
>
[[Sasha]] I am aware of at least two such independently developed and slightly different solutions.
>
>
>
>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

MINGUI> I think the two PEs sometimes deliver the frames directly rather than tunnel them. Therefore they need take forwarding decisions based on MAC addresses.

MINGUI> Anyway, I don’t think this feature will help to solve the black-hole issue. For example, suppose a remote end station is sending traffic to an end station attached to CE3 via PE1->PE2. Take this example to walk through bullet one in Section 2.2, you will see a black-hole.
>
[[Sasha]] I'd like to clarify that my problem is with the specific description of what you call a "private (proprietary?) solution" *as it appears in the draft*: there are neither remote end stations (and no indications as to how those could be included in the overall bridging domain) nor additional ports on PE1/PE2 in your diagram.
And you did not explain what happens to customer traffic received by PE1/PE2 from the "non-bridge" ports shown in the diagram. 
I agree that with a suitable extension the black-holing issue would become relevant - but *not with the topology that is actually depicted in the draft*.    
>
>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.

MINGUI> I don’t understand the logic that “because the customer traffic is tunneled, the black-hole issue disappears”. Without TCN snooping, there is a clear black-hole if you walk through the first bullet in Section 2.2. The tunneling of the customer traffic doesn’t help.
>
[[Sasha]] If ALL frames (customer and BPDU) received by PE1 from CE1 are tunneled to PE2 to be further transmitted to CE2 (and vice versa), this would be equivalent to connecting CE1 and CE2 by a physical P2P link. 
Since your diagram does not include any other players, your CEs would then  form a single bridged domain, and STP would handle link failures in this domain. Again, it is easy to extend your diagram in such a way that it would not work - but I am referring to what actually appears in the draft, not to what could be added to it!
>
>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.

MINGUI> Yes, we can detect the failure of the tunnel at the management plane. But it never tells us how to recover this failure. The slow STP convergence still exists.
>
[[Sasha]] I do not think that PWE3 should deal with improvements to STP. This protocol (in all its flavors) is owned by IEEE 802.1, and if it requires any improvements, they should be discussed there.  
>
>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.
>

MINGUI> For the argument on the scope, please read the first sentence of the last paragraph of [RFC6310].
>
[[Sasha]] I believe you refer to the last paragraph of the Introduction section of RFC 6310. If this is correct, then please take a look at the entire paragraph (quoted here for your convenience):
<quote>
   This document is scoped only to single segment PWs.  The mechanisms
   described in this document could also be applied to terminating PEs
   (T-PEs) for multi-segment PWs (MS-PWs) ([RFC5254]).  Section 10 of
   [RFC6073] details procedures for generating or relaying PW status by
   a switching PE (S-PE).
<end quote>
[[Sasha]] My reading of this paragraph is that it applies to T-PEs of MS-PWs without any changes (which is of course the proper scope  of OAM interworking since S-PEs do not have any attachment circuits), and that relay of PW status messages for carrying them end-to-end across a MS-PW is defined in RFC 6073.  
>
MINGUI> Let’s figure out the confusion. Maybe we can replace the full-mesh with multi-segment and tune that sentence.
>
[[Sasha]] Sorry, I cannot parse this statement. Could you please elaborate?
>
>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.

MINGUI> As we stated in Section 3, the ICCP draft provides the theory of operations in Section 9.2 for AC redundant applications.
>
[[Sasha]] Sorry, but IMO this is definitely not enough. Let's begin from the fact that Section 9.2 of the IICP draft discusses redundant pseudowires, but your draft refers to pseudowires only in one place (when it discusses the "private solution" and mentions that BPDUs are tunneled between PE1 and PE2 in a PW. 
>
>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?

MINGUI> That must be a complex mechanism. BUT, no migration is needed. ALL PEs connected to the STP network MUST run STP. You can find this sentence (All these ports emit configuration BPDU with the highest root priority to trigger the construction of the spanning tree.).
>
[[Sasha]] The sentence you have mentioned does not, by and of itself, mean that all PEs run STP. E.g., if you look at the "private solution" example and simply tunnel all traffic between CE1 and CE2 "as is", the CE-facing ports would emit BPDUs (with whatever root priority has been set to CE1 and CE2... Nor does it explain on which set of ports (in addition to CE-facing ones) STP runs in PE1 and PE2. 
>
>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.

MINGUI> I think technical merits are neither the whole story nor the sole reason that the solution should be adopted. 
Sometimes carriers don’t like a complex solution. Sometimes they don’t like a proprietary choice.
[[Sasha]] You have probably misunderstood my statement. I have said that I cannot discuss technical merits of the proposed solution because this solution is not presented in the draft.  Once you provide a detailed description of the solution (so that, as mentioned above, it could be implemented in an interoperable way by a reasonably qualified engineer based on the text you've written and your Normative references, it will be possible to discuss the technical aspects. 

>
>
>Hopefully these notes will be useful.

MINGUI> Thanks!

>
>
>
>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]>
>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]>
>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
>
>
>
>
>
>