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

Mingui Zhang <zhangmingui@huawei.com> Fri, 16 May 2014 01:31 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF3B1A06E8 for <pwe3@ietfa.amsl.com>; Thu, 15 May 2014 18:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYR-zwsYvE8J for <pwe3@ietfa.amsl.com>; Thu, 15 May 2014 18:31:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C471A06DD for <pwe3@ietf.org>; Thu, 15 May 2014 18:30:55 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU99457; Fri, 16 May 2014 01:30:46 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 02:30:05 +0100
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 02:30:45 +0100
Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.73]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 16 May 2014 09:30:35 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "Andrew G. Malis" <agmalis@gmail.com>
Thread-Topic: [PWE3] PWE3 WG last call for draft-ietf-pwe3-iccp-stp-01
Thread-Index: AQHPYDZEld3QSIBOQU+hJWPbTgqRFZs7e3wAgAKfigCAAB+eAIAETnPw
Date: Fri, 16 May 2014 01:30:34 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7336E3C2A@nkgeml508-mbx.china.huawei.com>
References: <CAA=duU2Rw=EyKV4OC9CfytCMdX9VoTP0EEk5iaoOz3O2=E1Oew@mail.gmail.com> <CAA=duU3oCX2E=ifoAkibr9m3Labgp35_-jzy_YgO8rauzEur6Q@mail.gmail.com> <CAA=duU0KSG-z3kesW--jdYYwAAqHdbXmz84ExP2egssudD=FfA@mail.gmail.com> <4e5ff4f0223e4a2296cacede2fc74c9f@AM3PR03MB612.eurprd03.prod.outlook.com>
In-Reply-To: <4e5ff4f0223e4a2296cacede2fc74c9f@AM3PR03MB612.eurprd03.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.175]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/94qCi_9IASwNULFkVMp_MgrpEC4
Cc: "pwe3@ietf.org" <pwe3@ietf.org>, "hujie@ctbri.com.cn" <hujie@ctbri.com.cn>
Subject: Re: [PWE3] PWE3 WG last call for draft-ietf-pwe3-iccp-stp-01
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Pseudowire Emulation Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3/>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 May 2014 01:31:11 -0000

Hi Sasha,

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

Mingui

>-----Original Message-----
>From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
>Sent: Tuesday, May 13, 2014 11:33 PM
>To: Andrew G. Malis
>Cc: pwe3@ietf.org; Mingui Zhang; Wenhuafeng; hujie@ctbri.com.cn
>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.

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

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

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

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

MINGUI> Let’s figure out the confusion. Maybe we can replace the full-mesh with multi-segment and tune that sentence.

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

>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.).

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

>
>
>Hopefully these notes will be useful.

MINGUI> Thanks!

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













>
>From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
>Sent: Tuesday, May 13, 2014 4:40 PM
>To: pwe3@ietf.org
>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 <agmalis@gmail.com>
>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 <agmalis@gmail.com>
>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
>
>
>
>
>
>