Re: [Pals] Progressing draft-busi-pals-pw-cw-stitching-01
Italo Busi <Italo.Busi@huawei.com> Tue, 05 February 2019 17:36 UTC
Return-Path: <Italo.Busi@huawei.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF213113C for <pals@ietfa.amsl.com>; Tue, 5 Feb 2019 09:36:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tWOr1-9Q3elV for <pals@ietfa.amsl.com>; Tue, 5 Feb 2019 09:36:38 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815FD130EAE for <pals@ietf.org>; Tue, 5 Feb 2019 09:36:38 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 46B313953DC274C67BE4; Tue, 5 Feb 2019 17:36:36 +0000 (GMT)
Received: from LHREML504-MBX.china.huawei.com ([10.201.109.60]) by lhreml701-cah.china.huawei.com ([10.201.108.42]) with mapi id 14.03.0415.000; Tue, 5 Feb 2019 17:36:35 +0000
From: Italo Busi <Italo.Busi@huawei.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
CC: "pals@ietf.org" <pals@ietf.org>, Shell Nakash <Shell.Nakash@ecitele.com>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Thread-Topic: Progressing draft-busi-pals-pw-cw-stitching-01
Thread-Index: AdS9WpkL9Hmxvb3RTY6aTiCs/BLvrQADXo2QAALJmtA=
Date: Tue, 05 Feb 2019 17:36:35 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B276B1C28@lhreml504-mbx>
References: <91E3A1BD737FDF4FA14118387FF6766B276B14AB@lhreml504-mbx> <AM0PR03MB38288E744F9D0212CEE9A86F9D6E0@AM0PR03MB3828.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB38288E744F9D0212CEE9A86F9D6E0@AM0PR03MB3828.eurprd03.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.251]
Content-Type: multipart/alternative; boundary="_000_91E3A1BD737FDF4FA14118387FF6766B276B1C28lhreml504mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/Q_EXodNEJwKa9nVmpAOjhL-uwpU>
Subject: Re: [Pals] Progressing draft-busi-pals-pw-cw-stitching-01
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2019 17:36:41 -0000
Hi Sasha, Thanks for your comment and for having brought to the table another alternative solution to the problem we are trying to solve Using H-VPLS for p2p services, even if possible, is not something I really like/prefer/advocate If the option to stitch the PW traffic at the Ethernet level is acceptable, I would prefer following the approach suggested by Matthew during IETF 103 which, as far as I have understood, is based on the MS-PW architecture rather than on H-VPLS architecture In both cases, stitching the PW traffic at the Ethernet level would work if and only if: - Ethernet PWs are the only PWs being deployed without the CW - These Ethernet PWs are always single-homed (i.e., no dual-homing, no PW redundancy) - It is acceptable to use Ethernet OAM instead of VCCV to monitor an MS-PW end-to-end (between the two T-PEs), e.g., for locating which PW segment is failed when the MS-PW is down A side question would also be how the network can be reconfigured without using the PW redundancy Italo From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: martedì 5 febbraio 2019 17:02 To: Italo Busi <Italo.Busi@huawei.com> Cc: pals@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com> Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01 Italo and all, I suspect that the problem which this draft tries to solve admits a simple solution that is fully covered by existing standards: the Hierarchical VPLS as defined in Section 10 of RFC 4762<https://tools.ietf.org/html/rfc4762> could be used without any changes: - T-PE1 and T-PE2 would treat S-PE 1 as their VPLS peer, but would not be aware of each other - S-PE1 would treat T-PE1 as a spoke peer and T-PE2 - as its core peer. It would do degenerated MAC-based switching between the two PWs it terminates (whatever comes in via one PW goes out via into the other one) - T-PE1 and T-PE 2 will also do degenerated MAC-based switching - Usage of the CW would be negotiated separately between each pair of VPLS peers - MAC-based switching in all the PEs would be configured not to apply any policing on BUM traffic. If MAC learning can be turned off, it would also help - Ethernet service OAM (as per IEEE 802.1ag or ITU-T Y.1731 would be fully applicable. What, if anything, did I miss? Is the situation when T-PE supports Ethernet PWs but does not support VPLS relevant in real deployments? Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com> -----Original Message----- From: Pals <pals-bounces@ietf.org<mailto:pals-bounces@ietf.org>> On Behalf Of Italo Busi Sent: Tuesday, February 5, 2019 4:02 PM To: pals@ietf.org<mailto:pals@ietf.org> Subject: [Pals] Progressing draft-busi-pals-pw-cw-stitching-01 During IETF 103, draft-busi-pals-pw-cw-stitching-01 has been presented and discussed We have received very valid technical comments that we think can be addressed in the future versions of the draft One of the main outstanding comment is about whether the solution proposed in the draft is addressing a real need in deployed networks The draft is proposing a solution that could resolve the issues described in RFC 8469 when PWs are deployed without the CW because an existing T-PE is not capable to insert the CW It is worth noting, as outlined during the IETF 103 discussion, that we are considering only T-PEs which are not capable to insert the CW because of hardware limitations and not T-PEs that are capable to insert the CW but configured not to do so. In the latter case, the solution in RFC 8469 (recommending to enable the use of CW) seems sufficient As outlined by Dave in the meeting notes, more analysis needs to be done on: 1. the use cases where this function would be used e.g., mobile transport? Ethernet enterprise services? data center interconnect? etc. 2. In these cases identified, how likely would it be where the TPE would not be upgraded? Since these issues are related to existing network deployments and future/planned network upgrades, we would appreciate any input from operators about these questions Thanks in advance Italo (on behalf of co-authors) _______________________________________________ Pals mailing list Pals@ietf.org<mailto:Pals@ietf.org> https://www.ietf.org/mailman/listinfo/pals ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
- [Pals] Progressing draft-busi-pals-pw-cw-stitchin… Italo Busi
- Re: [Pals] Progressing draft-busi-pals-pw-cw-stit… Alexander Vainshtein
- Re: [Pals] Progressing draft-busi-pals-pw-cw-stit… Italo Busi
- Re: [Pals] Progressing draft-busi-pals-pw-cw-stit… Alexander Vainshtein
- Re: [Pals] Progressing draft-busi-pals-pw-cw-stit… Alexander Vainshtein