From nobody Tue Feb 5 06:02:21 2019 Return-Path: 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 8DF3E1310C4 for ; Tue, 5 Feb 2019 06:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 sa7L9WktbNOe for ; Tue, 5 Feb 2019 06:02:15 -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 A652213110A for ; Tue, 5 Feb 2019 06:02:15 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 81AEC3EE32F674A4070B for ; Tue, 5 Feb 2019 14:02:13 +0000 (GMT) Received: from LHREML504-MBX.china.huawei.com ([10.201.109.60]) by LHREML711-CAH.china.huawei.com ([10.201.108.34]) with mapi id 14.03.0415.000; Tue, 5 Feb 2019 14:02:09 +0000 From: Italo Busi To: "pals@ietf.org" Thread-Topic: Progressing draft-busi-pals-pw-cw-stitching-01 Thread-Index: AdS9WpkL5kOT97WfRNugi8RYbpVEww== Date: Tue, 5 Feb 2019 14:02:08 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B276B14AB@lhreml504-mbx> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 14:02:21 -0000 During IETF 103, draft-busi-pals-pw-cw-stitching-01 has been presented and = discussed =A0 We have received very valid technical comments that we think can be address= ed in the future versions of the draft =A0 One of the main outstanding comment is about whether the solution proposed = in the draft is addressing a real need in deployed networks =A0 The draft is proposing a solution that could resolve the issues described i= n RFC 8469 when PWs are deployed without the CW because an existing T-PE is= not capable to insert the CW =A0 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 h= ardware limitations and not T-PEs that are capable to insert the CW but con= figured not to do so. In the latter case, the solution in RFC 8469 (recomme= nding to enable the use of CW) seems sufficient =A0 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 n= ot be upgraded?=20 =A0 Since these issues are related to existing network deployments and future/p= lanned network upgrades, we would appreciate any input from operators about= these questions Thanks in advance Italo (on behalf of co-authors) From nobody Tue Feb 5 08:02:24 2019 Return-Path: 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 CDB8F127B4C for ; Tue, 5 Feb 2019 08:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com 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 QW1_pVCCiVl6 for ; Tue, 5 Feb 2019 08:02:20 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.129]) (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 B5073130E16 for ; Tue, 5 Feb 2019 08:02:19 -0800 (PST) Received: from [46.226.53.55] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-c.eu-west-1.aws.symcld.net id 69/FD-08991-983B95C5; Tue, 05 Feb 2019 16:02:17 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSbUhTYRT2vffu7hpeeZvWTmZGK4SyrU2zDPs YUSRBtcAfFa66uptbbVfdnWRRIBlGRqlhVLMPNZPQEjQJzT7UotKKPiX7UFOXmWGZFVGhtLur ZX8OD8/znPM+5+UwpKqDDmH4DBfvFDi7hp5AzZ9hNGsPXt6YoC/vZ2OGB+sVMRdHKgkjEbf/9 oAirrT0J2EiNilsQmJKxlaF9e71g1SqJy3j9JcqlIk8lhw0gaFwCQmPWs8ROcifUeE8AoZGzJ Kgwh0Iclu+KSWBxkuguqKdzkEME4zDofL9FMlD4v0Ifl95r5A8QTgW+prafP5gvBie938bxZF w7FKHr5fCs8CTtVaiWWyGZ1ePKuV3V8DgyfO0hP3xSrhxa8jHIzwZfrRc9GUjsRpeec76MGAM pdcekTKeBB96RhSyPxE63xUjmZ8BJzpOKWU8DZ6ePYSkzICzlJBds08hC2tgcDgfSdkAz4SaP rPs6UHwvcCtkPk5cDSTk+12OP67brQ1FGrrGkfzZNOQM2CWd0mCe6e+UjIfBuWHuyh55mMS3G 0vKHkZAQbai4k8NNs9bjf3OMnt+6OJ0HzSQ8n8XCiqH6JlHAFlxR/JMfygoYcYzxchZTlamOi 0JVtdDs5m1xr0eq3BEKmN1EdpF0TquN3aJB2frt3Jiy6tQcftFHXiLkeS3aITeFc18l6WJfX+ 0lrUdyG5CU1hCM0kNmL7xgRVYGKKZZeVE61bnOl2XmxCoQyjAXZ5tVeb6OST+YxtNrv3PMdkY AI0wezzKq/MiqmcQ7Qly1ILWsY0lHSdJpkjVb3eWtMp1atSVVFCisCHqNlOaSqW2qzpwt+hY2 f/FE0LCWKRn5+fKiCVdzpsrv/1fqRmkCaI1UhTAmyC6+/b/d5YhDeWMHeDFMvF/ZNCMtGy8E9 5hWWxaUVl+pvrnix9+fXXm+EDJYLa9NnSPcu9ia6MOXxmJa02rV2/4+GdrEW5/lVT6/YmLVnY uCisO7591aGIAuMWm6m+IKHXmNZdOL2+MPf+UNTbNw2hxtX+8QH62LjmqY1o/qvmwM17+JnZa 6YrW8PzTTi6ovt1dExgrWOehhKtnGEO6RS5P25g7HfxAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-307.messagelabs.com!1549382533!1283489!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 23816 invoked from network); 5 Feb 2019 16:02:16 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-13.tower-307.messagelabs.com with AES256-SHA256 encrypted SMTP; 5 Feb 2019 16:02:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=baHjQBujwC6A7fdUwLt6YXOwiQrEUltzmxvy+Z8aTQA=; b=cBX/h/r4L1h5qZB0HzQ0aABjy3CRZfxXGvGSIfmZkNwdUzU7asgSu4fJto+oCQXEbV8mkkaGKxi+Ov+QOrCFMjdgExGK0asOQIEwpw0XIg3CweGQxFLGekG3FnaTGSgRHx5nFWmS2svogTBvUbDt85NVvi0DfJv0G9d8ZHp9ToA= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.29) by AM0PR03MB3890.eurprd03.prod.outlook.com (52.135.146.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17; Tue, 5 Feb 2019 16:02:12 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::4841:bfeb:3faa:e89f]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::4841:bfeb:3faa:e89f%6]) with mapi id 15.20.1580.019; Tue, 5 Feb 2019 16:02:12 +0000 From: Alexander Vainshtein To: Italo Busi CC: "pals@ietf.org" , Shell Nakash , Michael Gorokhovsky Thread-Topic: Progressing draft-busi-pals-pw-cw-stitching-01 Thread-Index: AdS9WpkL5kOT97WfRNugi8RYbpVEwwADXo2Q Date: Tue, 5 Feb 2019 16:02:12 +0000 Message-ID: References: <91E3A1BD737FDF4FA14118387FF6766B276B14AB@lhreml504-mbx> In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B276B14AB@lhreml504-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR03MB3890; 6:rCTm5sa+v25tPJZQOsu0LfR5LfJnaL7Xc3LPxWSDgX5JlQQBqd7eCQpielXGsVLcgwFyv0xwKUYaMQmwPLwQA3Czi5Z/vTwZMTqCXVnrKAvA0yeKM9A8DlGaPG34QpPe7knhj/WQu1HsgTqyoGdYIQLLdyuER0cKyrQn09zfpYKB5t5IcnmGqPtLHg0QgiHIX3lxhiQ2XARzVwDU5rjHf274SXf0Q2XR7X7UcPwA5y/5usJUYZt2VVhEdSwV86AtuUx9zg7lhkXfxoXRQpwFWVolwiazITjYtx+RpRz+365vTX7mzNi/ecN2YCmk/vREVhinXUmfRA4/M9d3wDtA+GnEBTpwURClQmyhzzTT8/P+QxJ2+fYQUtuYTY3sYHOr5eAVT/ZaSuzB3jEYdvBOblN/vm8qGi3EEeZjm4k+0JeNgCKoFi1VVoMmasAJAUt05ooCAop0QLHu18LvNLQRYA==; 5:PUfzbye8nIyUamT+ZqWli0FMxtDTEtMc28eMErxkIeAJmoSilLaUR6eb3RbBbI12mocunjrfin3DbxBU9QFCp0LgYYZ/IrHmxNwXoqzdp85t79QrJSK/XWBTyBnL+cNGZE3pq/ALnkToZ+NTNuw8t+psu2FP7mRP4VrCcEMOQg4pcBn2ri7WNsiBxRUks8YQaQihPl+b+QhISh6T8QfEGA==; 7:nBzhCxZ9sSUH5RB/faIKuJKBE56KRoqpQSZYEcAySqNUAcoBdSLGpE3rqOfXnBHUMZi0JQIFjaFcTKRNKSWGOh/Ty0Udpg8bU25f3XYB2V+Rl5YN0pTQBk8o7kzVOjmtRux4LY20NzmCNA6ukvAcUg== x-ms-office365-filtering-correlation-id: 1f17f76f-3c00-42e8-750a-08d68b834a60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR03MB3890; x-ms-traffictypediagnostic: AM0PR03MB3890: x-microsoft-antispam-prvs: x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(346002)(39860400002)(136003)(199004)(189003)(13464003)(51874003)(99286004)(72206003)(14454004)(33656002)(76176011)(966005)(478600001)(7696005)(66066001)(256004)(11346002)(446003)(107886003)(6246003)(53936002)(55016002)(54896002)(6306002)(71200400001)(236005)(9686003)(606006)(68736007)(71190400001)(6506007)(6916009)(6116002)(790700001)(3846002)(4326008)(486006)(7736002)(476003)(25786009)(74316002)(53546011)(26005)(316002)(229853002)(105586002)(97736004)(102836004)(2906002)(81166006)(8676002)(81156014)(106356001)(54906003)(86362001)(186003)(8936002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3890; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: raH6u43mpXcYo+CSajivKR0PbRz6Kof4PPiMg4LcUzyUO7kxvuO+wVElZ7Ft+rvd10Hr0lpAUJ7aZYOCd25g0NrV1uWFWg72HIHrvHxJcgQIJtfIiRJkLudTASlpUqiTblVw1PmAQTKmll2GtTPubsB/0WGQyv/sBqFVstt77/1ECcRE7W+C8kp3AV83pJoKknFRWzlIgLeQ/PZXtcIuwqAz3wRA33DBK+pSDyrsEbE/IHYvAT8AR3bW4ghOjjOqZD/qFhpAYS63IfxMZ34bh0EyqNKD4Oe8vNGi79fP+1kHySL9AOW+Bq5hq/mBxKOOMZ8rf7tGBsNq0BJELsZWFBY0DY2r8BdnlehRq7Dd+rhcmbF8QJmVccJBabZugz3OlQ1+q7Ou/uwAQPXvHhkKcQ5VqV73VndK7PfqYsYHPiU= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38288E744F9D0212CEE9A86F9D6E0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f17f76f-3c00-42e8-750a-08d68b834a60 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2019 16:02:12.2824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3890 X-CFilter-Loop: Reflected Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 16:02:23 -0000 --_000_AM0PR03MB38288E744F9D0212CEE9A86F9D6E0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 VP= LS as defined in Section 10 of RFC 4762 could be used without any changes: - T-PE1 and T-PE2 would treat S-PE 1 as their VPLS peer, but woul= d 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 pai= r of VPLS peers - MAC-based switching in all the PEs would be configured not to a= pply any policing on BUM traffic. If MAC learning can be turned off, it wo= uld 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 Etherne= t 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 -----Original Message----- From: Pals On Behalf Of Italo Busi Sent: Tuesday, February 5, 2019 4:02 PM To: 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 addres= sed 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 ar= e 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 (rec= ommending to enable the use of CW) seems sufficient As outlined by Dave in the meeting notes, more analysis needs to be done o= n: 1. the use cases where this function would be used e.g., m= obile transport? Ethernet enterprise services? data center interconnect? e= tc. 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 abo= ut these questions Thanks in advance Italo (on behalf of co-authors) _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB38288E744F9D0212CEE9A86F9D6E0AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Italo and all,

I suspect that the problem which this draft trie= s to solve admits a simple solution that is fully covered by existing stan= dards: the Hierarchical VPLS as defined in Section 10 of RFC 4762=20could be us= ed without any changes:

-      &nb= sp;   T-PE1 and T-PE2 would tre= at S-PE 1 as their VPLS peer, but would not be aware of each other

-      &nb= sp;   S-PE1 would treat T-PE1 a= s a spoke peer and T-PE2 – as its core peer. It would do degenerated MAC-based switching between the two PWs it termi= nates (whatever comes in via one PW goes out via into the other one)<= /o:p>

-      &nb= sp;   T-PE1 and T-PE 2 will als= o do degenerated MAC-based switching

-      &nb= sp;   Usage of the CW would be = negotiated separately between each pair of VPLS peers

-      &nb= sp;   MAC-based switching in al= l the PEs would be configured not to apply any policing on BUM traffic. If= MAC learning can be turned off, it would also help

-      &nb= sp;   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-549= 266302

Email:   Alexander.Vainshtein@ecitele.= com

 

-----Original Message-----
From: Pals <pals-bounces@ietf.org> On Behalf Of Italo Busi
Sent: Tuesday, February 5, 2019 4:02 PM
To: 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 t= hat we think can be addressed in the future versions of the draft

 

One of the main outstanding comment is about whe= ther the solution proposed in the draft is addressing a real need in deplo= yed networks

 

The draft is proposing a solution that could res= olve 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 t= o insert the CW because of hardware limitations and not T-PEs that are cap= able 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 a= nalysis needs to be done on:

        =         1. the use cases where this fun= ction would be used e.g., mobile transport? Ethernet enterprise services? = data center interconnect? etc.

        =         2. In these cases identified, h= ow likely would it be where the TPE would not be upgraded?

 

Since these issues are related to existing netwo= rk deployments and future/planned network upgrades, we would appreciate an= y input from operators about these questions

 

Thanks in advance

 

Italo (on behalf of co-authors)

 

_______________________________________________<= o:p>

Pals mailing list

Pals@ietf.org=

https://www.i= etf.org/mailman/listinfo/pals


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB38288E744F9D0212CEE9A86F9D6E0AM0PR03MB3828eurp_-- From nobody Tue Feb 5 09:36:42 2019 Return-Path: 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 ; 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 ; 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 ; 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 To: Alexander Vainshtein CC: "pals@ietf.org" , Shell Nakash , Michael Gorokhovsky Thread-Topic: Progressing draft-busi-pals-pw-cw-stitching-01 Thread-Index: AdS9WpkL9Hmxvb3RTY6aTiCs/BLvrQADXo2QAALJmtA= Date: Tue, 5 Feb 2019 17:36:35 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B276B1C28@lhreml504-mbx> References: <91E3A1BD737FDF4FA14118387FF6766B276B14AB@lhreml504-mbx> In-Reply-To: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 17:36:41 -0000 --_000_91E3A1BD737FDF4FA14118387FF6766B276B1C28lhreml504mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sasha, Thanks for your comment and for having brought to the table another alterna= tive 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 rat= her 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 se= gment is failed when the MS-PW is down A side question would also be how the network can be reconfigured without u= sing the PW redundancy Italo From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: marted=EC 5 febbraio 2019 17:02 To: Italo Busi Cc: pals@ietf.org; Shell Nakash ; Michael Gorokho= vsky 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 = 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 te= rminates (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 ap= ply any policing on BUM traffic. If MAC learning can be turned off, it woul= d 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 -----Original Message----- From: Pals > On Behalf = Of Italo Busi Sent: Tuesday, February 5, 2019 4:02 PM To: 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 address= ed 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 i= n 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 h= ardware limitations and not T-PEs that are capable to insert the CW but con= figured not to do so. In the latter case, the solution in RFC 8469 (recomme= nding 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., mo= bile 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/p= lanned 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 https://www.ietf.org/mailman/listinfo/pals ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original and all copies thereof. ___________________________________________________________________________ --_000_91E3A1BD737FDF4FA14118387FF6766B276B1C28lhreml504mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sasha,

 

Thanks for your commen= t and for having brought to the table another alternative solution to the p= roblem we are trying to solve

 

Using H-VPLS for p2p s= ervices, even if possible, is not something I really like/prefer/advocate

 

If the option to stitc= h the PW traffic at the Ethernet level is acceptable, I would prefer follow= ing the approach suggested by Matthew during IETF 103 which, as far as I ha= ve understood, is based on the MS-PW architecture rather than on H-VPLS architecture

 

In both cases, stitchi= ng the PW traffic at the Ethernet level would work if and only if:

-&n= bsp;         Ethernet PWs a= re the only PWs being deployed without the CW

-&n= bsp;         These Ethernet= PWs are always single-homed (i.e., no dual-homing, no PW redundancy)<= /o:p>

-&n= bsp;         It is acceptab= le to use Ethernet OAM instead of VCCV to monitor an MS-PW end-to-end (betw= een 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=EC 5 febbraio 2019 17:02
To: Italo Busi <Italo.Busi@huawei.com>
Cc: pals@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; Mi= chael 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 standa= rds: the Hierarchical VPLS as defined in Section 10 of RFC 4762 could be used = without any changes:

-       = ;   T-PE1 and T-PE2 would treat S-PE 1 as their VPLS pe= er, but would not be aware of each other

-       = ;   S-PE1 would treat T-PE1 as a spoke peer and T-PE2 &= #8211; as its core peer. It would do degenerated MAC-based switching between the two PWs it termin= ates (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 betw= een each pair of VPLS peers

-       = ;   MAC-based switching in all the PEs would be configu= red 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 w= hen T-PE supports Ethernet PWs but does not support VPLS relevant in real d= eployments?

 

Regards, and lots of thanks in advance,

Sasha

 

Office: +972-39266302

Cell:      +972-5492= 66302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message-----
From: Pals <pals-bounces@ietf.o= rg> On Behalf Of Italo Busi
Sent: Tuesday, February 5, 2019 4:02 PM
To: 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 th= at we think can be addressed in the future versions of the draft=

 

One of the main outstanding comment is about whet= her the solution proposed in the draft is addressing a real need in deploye= d networks

 

The draft is proposing a solution that could reso= lve the issues described in RFC 8469 when PWs are deployed without the CW b= ecause an existing T-PE is not capable to insert the CW

 

It is worth noting, as outlined during the IETF 1= 03 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 capabl= e to insert the CW but configured not to do so. In the latter case, the solution in RFC 8469 (recommending t= o enable the use of CW) seems sufficient

 

As outlined by Dave in the meeting notes, more an= alysis needs to be done on:

        &= nbsp;       1. the use cases where this funct= ion would be used e.g., mobile transport? Ethernet enterprise services? dat= a center interconnect? etc.

        &= nbsp;       2. In these cases identified, how= likely would it be where the TPE would not be upgraded?

 

Since these issues are related to existing networ= k 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

https://www.iet= f.org/mailman/listinfo/pals


___________________________________________________________________________=

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
___________________________________________________________________________=

--_000_91E3A1BD737FDF4FA14118387FF6766B276B1C28lhreml504mbx_-- From nobody Wed Feb 6 08:09:12 2019 Return-Path: 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 C962D12EB11 for ; Wed, 6 Feb 2019 08:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com 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 SQpWVddwRFvx for ; Wed, 6 Feb 2019 08:09:07 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.117]) (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 EB07112E036 for ; Wed, 6 Feb 2019 08:09:06 -0800 (PST) Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-b.eu-central-1.aws.symcld.net id 19/3A-13671-0A60B5C5; Wed, 06 Feb 2019 16:09:04 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGuTPT6UAYvZalR2SJVXGdBlSUuAR DglviGo1EQZ3CSBvaaWmLVl9ERR8wIgkYgeACVqMFUQhRogJSJVE0irjGKEtcgBqNRkSRSOx0 UPHl5rv/f+5Zbg5DqrrpMEZw2AWryBs1dAA1d0KdgztJb0mJ8ZTExf/6fF0RXzVcTSwhlufe/ qhY7nQOEmuJzQqDqDM7tiv0T/fXE5bbA8hRdv4WlYNOv0J5KIChcAUJnp5BSrqo8FECGpucSv nSgaDq3gU6D/kzNF4MtZWvvcwwwTgaqnvGSzEkzkUwdKVHIcUE4YXQ636hlDgYL4Innv4RToS hGzmExBSeDFeHX/uYxalw5ud3hVysDcHV9kpKMvxxEriHHvuCEA6F761VPiaxGl6+PeVjwBic Nx6SModA35thhRyvg8535UjWJ0JxR5lS5ghoP3V4RD+ghMGWeJlXQf2Xi0gaDPAkqOtNleU3C C7lrJPlGfDrm78sG+HBQPFIlnB4fLmQltoHXEDDT2eRr5QKp8Gdsq+UHBQJriPdI9xGQl/FGH kUEa4X3iMK0PTSUZOVjrJKfV80Du6WvKVkXQsvjhXRMs+Ec+UfSJk5KB52U6P100jpQvN1VkO G3m7iDUYuNiaGi42dw83l5mn5PZxOK2RzaYJot/JeT8vvsmltu01pxnStKNhrkXe50rMouh41 5GW40XiG0ISws3ZuTlGN0ZnTd+t5m36bNdso2NwonGE0wC5SbElRjbMKGYJjh8Ho3dA/NjCBm mAWSTZrs/AmmyFDtlpRAnOzovsEyeTXvPeedZ3SeU06VZRoFoUwNdsqPcPSM322+Dfpn81vRx FhQSzy8/NTBVoEq8lg/9/3IDWDNEHsWClLoEG0/63t8bZFeNsSZyVLbdn5f1ZYDspeVqM+3rS HT0nMqmlmXV3ro0LPrE462DxtZmbfutCY9Oipm1yPZicsNXOH4qn7cd3ze1d25J88q/90fCCg vL/xuSX6We3njQt2TYsyrInrdzRscETuNbdkTfli2mftmrMiZFnyVpU607VYb899mPWguX1sZ e6PkpbwNk1my1bLq+d+Gsqm52NnkFYb/xsMhgzv9AMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-24.tower-245.messagelabs.com!1549469339!1343325!1 X-Originating-IP: [52.27.180.120] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 2018 invoked from network); 6 Feb 2019 16:09:01 -0000 Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (52.27.180.120) by server-24.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 6 Feb 2019 16:09:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xRpBRFCFC8ooCC/vtbqpnYcHndmCvyJPnOPPUCLQm00=; b=lIcnxIUhGkQ2j8VisW0M7FHwwQz+A1iFjZZxJHhu/g4d1cYNZbQrOrQEnQZTNEvu4K6ATIVa8NiYyx5ybAV8rztiaKtX3MFek3JxC0S78jumQsWynWlwgtYi9xAYGUJIpI6YwesaDtGUVJ2gkTUfnH2o2wNaI6y0irue2zZKbKY= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.29) by AM0PR03MB4337.eurprd03.prod.outlook.com (20.176.215.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.19; Wed, 6 Feb 2019 16:08:57 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::4841:bfeb:3faa:e89f]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::4841:bfeb:3faa:e89f%6]) with mapi id 15.20.1601.016; Wed, 6 Feb 2019 16:08:57 +0000 From: Alexander Vainshtein To: Italo Busi CC: "pals@ietf.org" , Shell Nakash , Michael Gorokhovsky Thread-Topic: Progressing draft-busi-pals-pw-cw-stitching-01 Thread-Index: AdS9WpkL5kOT97WfRNugi8RYbpVEwwADXo2QAARQ9IAALbYMUA== Date: Wed, 6 Feb 2019 16:08:57 +0000 Message-ID: References: <91E3A1BD737FDF4FA14118387FF6766B276B14AB@lhreml504-mbx> <91E3A1BD737FDF4FA14118387FF6766B276B1C28@lhreml504-mbx> In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B276B1C28@lhreml504-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR03MB4337; 6:s8OHJ8M/XlAaHgKdwpbB49dFBvn+TQg8bT3nC4fqkJxyvXU8tcKEOj8kxkxo3fpHHVneyq6NsBPul2m4eOEseX2gHguFQL2DtrOy/I/pFKQ620TRPBN861ETQPN2FdIpLgpEdWHqYLiEC980G710TP2nD+K1/H1l3DYdq+RpZVPrdoDARyCfs+WaSf/JOrW8+EdM2mk1tzcuONGfTsR6N+EoZa5mQMV49SuUmMOw9SM+orGgIHeU0erhZ3VVPmsN0ML9xUDv0s+0FfvZDBxZjJi+2B879qeoKNxsSrruudVAKV0Y5YoKb39iJUjF5Ouzazu6rTd8+h6UVEscEZOb1ZBua5YJwYi2p1chsXWgqWKXhKV9phjbc3MHw/c6qEcTP086L8imqtHiHz7C6AJ1iJGjrATMyyQjmcTbN1rVR8qbUcbWlqxdC0vOUdapac3W7uKl8b3xMdfDhZoxyeE9Hw==; 5:7xPlREvyBUSLb0OdmGVxuvgOPE0Mlfrtqil8mWA2P917eVRtcsx/wOwF1BhyKYf99SHeeM9vE4PCP/oPYdnPpA+JbPjUcR5vBEY/7dO5OwUJ7zvasrYU91tBgb0u5LXPl5Mi3GFlMyTdiJ7XnKMulCu5QF/r9RzNxRjJL/w6DcVyS20Eh8JDd4s3vhP/yreoYrZ+YH8Ho/ylV/sxI91GDQ==; 7:VtJ5sB5TWWpNLHKRmS6HbnXOVSwUtWBb8WqRD3JjHdhKWySFRr4vouMMexOuF4+NhPS37/1qsBhguMebwjTeivIsriUy7xnl0bvkTc2t7ZheSLh7i+J59Xp5YuqprB+5Wq3I+RfzbMVrw/PIOVpJtw== x-ms-office365-filtering-correlation-id: 74cf80bb-633f-4f1a-912d-08d68c4d6655 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR03MB4337; x-ms-traffictypediagnostic: AM0PR03MB4337: x-microsoft-antispam-prvs: x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(396003)(366004)(39860400002)(199004)(189003)(13464003)(51874003)(7736002)(74316002)(81156014)(81166006)(8676002)(8936002)(6436002)(99286004)(76176011)(14444005)(256004)(68736007)(186003)(11346002)(53546011)(55016002)(6306002)(9686003)(54896002)(236005)(71200400001)(71190400001)(476003)(102836004)(7696005)(97736004)(6506007)(446003)(14454004)(53936002)(72206003)(966005)(33656002)(606006)(107886003)(6246003)(4326008)(86362001)(26005)(6116002)(3846002)(790700001)(486006)(105586002)(106356001)(66066001)(229853002)(25786009)(54906003)(2906002)(316002)(478600001)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4337; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UCpNWURaqf9bJ+M3KyRdwU6i/lyEVF8s20KCrvnFYCmV+wHA5k8eGy1yLWxHzopLNq4Q8ZxzhoxL2VlsXGzpzUbTZ87SuirKUedYxSh4YCLiVXU7OHWNLXuik5iJIJwrbJoDQAWnklNHO2lFsTBNEx8IwDrfaASdpW9VRSq1Y0vQIfiAI7nKsw4je+/exLvY6RuXcXau0cQTe90oaozPXDhdyESn1is2DOM9rS22e95EIRhfg6Qs3X5Wo2/jjimhAWzAq78wdaRwbPh2+eDg+Sm4iwYNwcFf3L1zNDcVC6iKwtxYD2rvQgqN31jR+eByDguISRow8quSuO6k8YReNp5O8rivcsYWaaisCX3dqKRYU/dEhoaJHJnL3BjjUKZxkk58slhNcJKvHDRZdrKwgW5wgs3xlykRGJVwEf/vTyw= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38286E44D87253FF261013A49D6F0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74cf80bb-633f-4f1a-912d-08d68c4d6655 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 16:08:57.5897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4337 X-CFilter-Loop: Reflected Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 16:09:11 -0000 --_000_AM0PR03MB38286E44D87253FF261013A49D6F0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Italo, Lots of thanks for a prompt response. Please see answers to some of your questions inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Italo Busi Sent: Tuesday, February 5, 2019 7:37 PM To: Alexander Vainshtein Cc: pals@ietf.org; Shell Nakash ; Michael Gorokh= ovsky Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01 Hi Sasha, Thanks for your comment and for having brought to the table another altern= ative solution to the problem we are trying to solve Using H-VPLS for p2p services, even if possible,[[Sasha]] It is definitely= 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 1= 03 which, as far as I have understood, is based on the MS-PW architecture = rather than on H-VPLS architecture [[Sasha]] My reading of the minutes (copied below for your convenience) is= different: Matthew: are you doing a label swap and adding a CW added? Italo: Yes Matthew: The architecture doesn't allow it. You are really stitching the= two PWs together, after having gone to the Ethernet frame and then pushin= g the label stack with the CW. This is in the architecture. Change the d= raft to point to that. Stewart: OK Himanshu: So this isn't a switching PE, it's a tear down and rebuild of t= he stack? Stewart: Yes, with end to end OAM. Himanshu: But everything terminates. It's not native, and not end to end i= f it terminates. Matthew: Could do the OAM at the Ethernet level, but not VCCV Stewart: OK there is some work to be done. I.e., according to Matthew, what you have proposed does not match the MS-P= W architecture, and you cannot run end-to-end PW OAM, only Ethernet OAM. In both cases, stitching the PW traffic at the Ethernet level would work i= f and only if: - Ethernet PWs are the only PWs being deployed without the CW[[Sa= sha]] From my POV, RFC 7079 strongly suggest that this was the case even 5= .5 years ago. Since then I think the dominance of Ethernet PWs has only in= creased. - These Ethernet PWs are always single-homed (i.e., no dual-homin= g, no PW redundancy)[[Sasha]] H-VPLS can use PW redundancy as well I think= . What can be achieved with such a mechanism depends on what you are looki= ng for. - 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[[Sasha]] You can use Ethernet ser= vice OAM link trace for that. 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=EC 5 febbraio 2019 17:02 To: Italo Busi > Cc: pals@ietf.org; Shell Nakash >; Michael Gorokhovsky > 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 VP= LS as defined in Section 10 of RFC 4762 could be used without any changes: - T-PE1 and T-PE2 would treat S-PE 1 as their VPLS peer, but woul= d 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 pai= r of VPLS peers - MAC-based switching in all the PEs would be configured not to a= pply any policing on BUM traffic. If MAC learning can be turned off, it wo= uld 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 Etherne= t 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 -----Original Message----- From: Pals > On Behalf= Of Italo Busi Sent: Tuesday, February 5, 2019 4:02 PM To: 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 addres= sed 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 ar= e 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 (rec= ommending to enable the use of CW) seems sufficient As outlined by Dave in the meeting notes, more analysis needs to be done o= n: 1. the use cases where this function would be used e.g., m= obile transport? Ethernet enterprise services? data center interconnect? e= tc. 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 abo= ut these questions Thanks in advance Italo (on behalf of co-authors) _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this transmission in error, please inform us by e-mail, phone or fax, and then = delete the original and all copies thereof. __________________________________________________________________________= _ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI=20Telecom. If you have re= ceived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB38286E44D87253FF261013A49D6F0AM0PR03MB3828eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Italo,

Lots of thanks for a = prompt response.

Please see answers to= some of your questions inline below.

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Al= exander.Vainshtein@ecitele.com

 

From: Italo Busi <Italo.Busi@huawei.com&g= t;
Sent: Tuesday, February 5, 2019 7:37 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Cc: pals@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; M= ichael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01

 

Hi Sasha,<= /span>

 

Thanks for your comme= nt 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,[[Sa= sha]] It is definitely possible  is not something I really like/prefer/advocate<= /p>

 

If the option to stit= ch the PW traffic at the Ethernet level is acceptable, I would prefer foll= owing 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

[[Sasha]] My re= ading of the minutes (copied below for your convenience) is different:

Matthew: are you doing a label swap and addi= ng a CW added? 

Italo: Yes

Matthew:  The architecture do= esn't allow it.  You are really stitching the two PWs together, after= having gone to the Ethernet frame and then pushing the label stack with t= he CW.  This is in the architecture.  Change the draft to point to that.

Stewart: OK

Himanshu:  So this isn't a swi= tching PE, it’s a tear down and rebuild of the stack?

Stewa= rt: Yes, with end to end OAM.

Himan= shu:=20But everything terminates. It's not native, and not end to end if i= t terminates.

Matth= ew: Could do the OAM at the Ethernet level, but not VCCV

Stewart: OK there is some work to be done.

I.e., according= to Matthew, what you have proposed does not match the MS-PW architecture,= and you cannot run end-to-end PW OAM, only Ethernet OAM.

 

In both cases, stitch= ing the PW traffic at the Ethernet level would work if and only if:

-=           Ethernet PWs are the only PWs being deployed without the CW[[Sasha]] From my POV, RFC 7079 st= rongly suggest that this was the case even 5.5 years ago. Since then I think the dominance of Ethernet PWs has only = increased.<= /p>

-=           These Ethernet PWs are always single-homed (i.e., no dual-homi= ng, no PW redundancy)[[Sasha]] = H-VPLS can use PW redundancy as well I think. What can be achieved with such a mechanism depends on what you are lookin= g for.

-=           It is acceptable to use Ethernet OAM instead of VCCV to monito= r 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[[Sasha]] You can use Ethernet service OAM link trace for that.

 

A side question would= also be how the network can be reconfigured without using the PW redundan= cy

 

Italo

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.co= m]
Sent: marted=EC 5 febbraio 2019 17:02
To: Italo Busi <Italo.B= usi@huawei.com>
Cc: pals@ietf.org; Shell Nakas= h <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 trie= s to solve admits a simple solution that is fully covered by existing stan= dards: the Hierarchical VPLS as defined in Section 10 of RFC 4762 could be used= without any changes:

-      &nb= sp;   T-PE1 and T-PE2 would tre= at S-PE 1 as their VPLS peer, but would not be aware of each other

-      &nb= sp;   S-PE1 would treat T-PE1 a= s a spoke peer and T-PE2 – as its core peer. It would do degenerated MAC-based switching between the two PWs it termi= nates (whatever comes in via one PW goes out via into the other one)<= /o:p>

-      &nb= sp;   T-PE1 and T-PE 2 will als= o do degenerated MAC-based switching

-      &nb= sp;   Usage of the CW would be = negotiated separately between each pair of VPLS peers

-      &nb= sp;   MAC-based switching in al= l the PEs would be configured not to apply any policing on BUM traffic. If= MAC learning can be turned off, it would also help

-      &nb= sp;   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-549= 266302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message-----
From: Pals <pals-bounces@ietf.= org> On Behalf Of Italo Busi
Sent: Tuesday, February 5, 2019 4:02 PM
To: pals@ietf.org
Subject: [Pals] Progressing draft-busi-pals-pw-cw-stitching-01<= /p>

 

During IETF 103, draft-busi-pals-pw-cw-stitching= -01 has been presented and discussed

 

We have received very valid technical comments t= hat we think can be addressed in the future versions of the draft

 

One of the main outstanding comment is about whe= ther the solution proposed in the draft is addressing a real need in deplo= yed networks

 

The draft is proposing a solution that could res= olve 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 t= o insert the CW because of hardware limitations and not T-PEs that are cap= able 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 a= nalysis needs to be done on:

        =         1. the use cases where this fun= ction would be used e.g., mobile transport? Ethernet enterprise services? = data center interconnect? etc.

        =         2. In these cases identified, h= ow likely would it be where the TPE would not be upgraded?

 

Since these issues are related to existing netwo= rk deployments and future/planned network upgrades, we would appreciate an= y input from operators about these questions

 

Thanks in advance

 

Italo (on behalf of co-authors)

 

_______________________________________________<= o:p>

Pals mailing list

Pals@ietf.org=

https://www.i= etf.org/mailman/listinfo/pals


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB38286E44D87253FF261013A49D6F0AM0PR03MB3828eurp_-- From nobody Wed Feb 6 08:30:11 2019 Return-Path: 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 864F112D4EB for ; Wed, 6 Feb 2019 08:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com 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 gCFW0k1fNPfd for ; Wed, 6 Feb 2019 08:30:08 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.131]) (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 9B2DE124BF6 for ; Wed, 6 Feb 2019 08:30:07 -0800 (PST) Received: from [46.226.53.55] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.eu-west-1.aws.symcld.net id 3C/80-07988-D8B0B5C5; Wed, 06 Feb 2019 16:30:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGuTPTdkQqt2U7ENFQjDFCG0pQcUP 0wWCIxieDQMUBxrZaBtIpUH0wxAVMFVywiqhBCGtFFEKMiiZIjAsJEauJQhRDqLKJIcG4W+x0 quLLmf/e/zv3nDM5NKl0SSNo1mphzRxjUkn9qYSoZJ26fH5GZly3g078Nd0lSWx1txHJRMqRB 1OSlPr6b8R2Il1i5LLzrbslBufzLqLglp2wvr83KSlBlV+RDfnTFK4joa+0TCYclLiCgKHvNi QehhD0245TNjSPluL10HH1jdSGaDoYL4W20XCBIfERBD9ujkoEJgivhbGeVzJBB+N18GLik09 vhrKWdkLQFF4Cs29qkaDlWAcf7F2+ys8Q1Nxs9hoIh8KX3lZvAonDYNBV49WAMdTffUqKOgTG R9wSkc+Gt+/ERwFHQdXQJZmoI8FZc9w7DeDDMjg5MkuJxlZ40n2CEKYBHA2dYzqRGUHQMdggF ZnlcHvqpU+b4NDgUV/uQnh+o1IqJpRKYXL6urcLJc6Bx5dmfNAicJQPUyLUT8Lna8e8/47EHE w2RIvjK+DJBRd1Ci2rnjNo9T+qeg4lIhp4ZT8rFXUMNNZOkqJWQ5W7h5p7fwXJHCgx22zUGyx 5jNGk1sbFqbXaeHW895uoYQ6oczRsobqY5S1qrYYp5jX8/rwcU66GYy0dyLNfuQWPi26hc836 HhROE6oQeWxReqZyQXZ+7n4DwxuyzIUmlu9BC2laBfIm/4xMpcLM6lnrHqPJs6R/bKADVMHyL MGW8wVMHm/Ui1Yv2kB31w1fJumK9vee2PlWiHeEqKS4fI6NCJO75nnSsJBmKOT+Pvpn+Z0oMi JIjvz8/JQBBaw5z2j5359AYTRSBckdQvEAI2f5W3vC0xbhaYuLTRPasjD/rIgSdDc8tmW65LW ucbH9vCI55U5szEDngciBc1nWg/rUNctSgyXEVHrSqiarpu1k0mzVlTMVa0LLFc19DbKtq/ft rb3c/m7vJteuHcfKA0vp9c7Ki87ANN3p3qX14+6chOiBH0kxIR8V9hVrZ0YfDh0K352RuvH+l rLAlT8tXx+ddeu2he5UUbyB0S4nzTzzG0RvLF33AwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-307.messagelabs.com!1549470601!1359670!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 7839 invoked from network); 6 Feb 2019 16:30:04 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-6.tower-307.messagelabs.com with AES256-SHA256 encrypted SMTP; 6 Feb 2019 16:30:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=76kcaVmTsgVE75PJwoY5slNU2AUhWusYkO9uDEnetyM=; b=Xggu1BCkgZde5UirrHjt/tbPDo23ta7bA685XS70GIgRJvrcn0Wg3GGH4LpeZGKWcZ56UJ9x26S1kygKaW96SM4RblihH1Hq3bOkzNVCEA0MhbXfowJU1hOk8GmoVBXeADSlXnEvvSqUWfm10in16euvcc3SofgWkraK95sm98w= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.29) by AM0PR03MB4802.eurprd03.prod.outlook.com (20.178.21.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17; Wed, 6 Feb 2019 16:29:59 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::4841:bfeb:3faa:e89f]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::4841:bfeb:3faa:e89f%6]) with mapi id 15.20.1601.016; Wed, 6 Feb 2019 16:29:59 +0000 From: Alexander Vainshtein To: Italo Busi CC: "pals@ietf.org" , Shell Nakash , Michael Gorokhovsky Thread-Topic: Progressing draft-busi-pals-pw-cw-stitching-01 Thread-Index: AdS9WpkL5kOT97WfRNugi8RYbpVEwwADXo2QAARQ9IAALbYMUAAB/2AA Date: Wed, 6 Feb 2019 16:29:59 +0000 Message-ID: References: <91E3A1BD737FDF4FA14118387FF6766B276B14AB@lhreml504-mbx> <91E3A1BD737FDF4FA14118387FF6766B276B1C28@lhreml504-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR03MB4802; 6:bytO/xDeJ2aXAGDQgWYLfs8jdGmFd0TNKR+0djP3kGDEuY+2FlH4K8gpmoUqsV/Vj9AAVYCoGH6uIEuqxOHvnJB4PRYQLuRvnapyUObU8i7L8RvciWzBjlGxmO3yTchwgmBG1sjDpDqtJAn0eoF4TtPvgfBTwDuGpi/cUlHnOMdl6+E9Ynv8Q5Gt1DPuFYYwAPY3fr6bCaM/JE77qPy1ORaMEIJXPCiQCTMkL/0Nt2QWDsX2pEY0mRn4snV8w0meW3gQ5c2MG1+QgRZNha6kFYBpuAUhc9BY4kh2BAlgKGRjFuOjDg2PImR51TUz5Bu8ButLcoq1eBD2KPH/c5licJgfIohQDtYaqko7mi4aY1c96Uy5UDuwrSevLiFoxhYO9Bz3SRls47gN3Dm2f608Zcj1qLjWpowBU+e+gxlQewW18VEuy3KdXkItvhQtwWHo39JWHOKGpNKBeq9BqcCltw==; 5:lh8aCi+DZqtrX0mONTlSkaTpxmBkknFWikYDZWQcXIM491JqMzu12QPGpN9JARFzRoVvaadNXRS74OZw8kbj2GVwfoANmjvJcRAnKpbdxBReioDX7VcRHxTq4C+HtX3PPJ97ixBEX/nnbKXN7GB6XmRSxwbbpuMrTP0cbibRWMm95x0NrJwpk+3abeJt09Ks7KUasZ/zgAPXa1ena0p2Vw==; 7:n0x3M3QoccYh6yInhvye5ZuOpkL4cV9j/FHE8UMtOv6GSNikd7jJ+MiRqPJD8Wwl3gHRYZ3bE689RRMlzpC9OAcEvUJsicI7rriX5rRQdZo7T5gQWNvrh9AXJkyBMWnF/HJskGeghSAZMjHFI4o1wQ== x-ms-office365-filtering-correlation-id: 979b3443-a914-4ecf-e2b4-08d68c505650 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR03MB4802; x-ms-traffictypediagnostic: AM0PR03MB4802: x-microsoft-antispam-prvs: x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(366004)(39860400002)(396003)(376002)(199004)(189003)(13464003)(51874003)(106356001)(2906002)(6116002)(54896002)(14454004)(54906003)(76176011)(3846002)(790700001)(9686003)(8936002)(966005)(478600001)(55016002)(6436002)(7736002)(256004)(14444005)(316002)(33656002)(74316002)(236005)(7696005)(446003)(72206003)(6306002)(229853002)(476003)(606006)(68736007)(86362001)(53546011)(53936002)(6916009)(99286004)(4326008)(8676002)(486006)(25786009)(81156014)(81166006)(71190400001)(26005)(107886003)(6246003)(66066001)(97736004)(71200400001)(6506007)(105586002)(102836004)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4802; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: f+dK6pRwPiCYXBTeIiA+qY1cBolpf8f3whDgQSrpaMs85vIz8VSRDgf7rpGDeozE/s9KFliBhprEeGruz/TJZ0Qvq1oUUr9FvrXZSdNzRbjDMx6wIzQ3utDH/IEhFbpMIidPDy7h00QS5DPSkY33/N9eV7Ltv6aSo+aEPs8cfztZLLl/qhw7zDp1sceyTeS8iDzm70LxfoBc+AIIU9BW5Vaysoa+iB46b5BqyOeHbmhyCkFgf5NewYlSv5YES/k6h6z9fVBKY5uT+Bl/hX8CMJacIAR+tUpUCYkieZo6VgJ9hjfwm8uWsE92FhbPm3gYDwkVoL7Yx0B/Sj/xgX1iCfPFBKQMmN4qMcHF/3Z0aofVw2InoB99e0ROfEBimIsRLLO5oR6qnOPffDL41567kvzmShBCaXym6z/vAHvKGEU= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828FD94804699BA5FE4F8179D6F0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 979b3443-a914-4ecf-e2b4-08d68c505650 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 16:29:59.2037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4802 X-CFilter-Loop: Reflected Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 16:30:10 -0000 --_000_AM0PR03MB3828FD94804699BA5FE4F8179D6F0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Italo, Was your last question was about migrating from a single-segment PW (witho= ut the CW) to the new solution (whatever it can be) with minimal impact on= traffic? This is a good question and the answer is implementation-specific I think.= But generally speaking you could configure your H-VPLS first (with the PWs= set up and all), and then transfer your ACs in TP-1 and TP-2 from the ori= ginal PW endpoints to the VSI in these devices in a coordinated management= action. Such a transfer would be, of course, traffic-affecting, but, hope= fully, the hits would be short enough. Not very complicated with proper ne= twork management I think. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Alexander Vainshtein Sent: Wednesday, February 6, 2019 6:09 PM To: 'Italo Busi' Cc: pals@ietf.org; Shell Nakash ; Michael Gorokh= ovsky Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01 Italo, Lots of thanks for a prompt response. Please see answers to some of your questions inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Italo Busi > Sent: Tuesday, February 5, 2019 7:37 PM To: Alexander Vainshtein > Cc: pals@ietf.org; Shell Nakash >; Michael Gorokhovsky > Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01 Hi Sasha, Thanks for your comment and for having brought to the table another altern= ative solution to the problem we are trying to solve Using H-VPLS for p2p services, even if possible,[[Sasha]] It is definitely= 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 1= 03 which, as far as I have understood, is based on the MS-PW architecture = rather than on H-VPLS architecture [[Sasha]] My reading of the minutes (copied below for your convenience) is= different: Matthew: are you doing a label swap and adding a CW added? Italo: Yes Matthew: The architecture doesn't allow it. You are really stitching the= two PWs together, after having gone to the Ethernet frame and then pushin= g the label stack with the CW. This is in the architecture. Change the d= raft to point to that. Stewart: OK Himanshu: So this isn't a switching PE, it's a tear down and rebuild of t= he stack? Stewart: Yes, with end to end OAM. Himanshu: But everything terminates. It's not native, and not end to end i= f it terminates. Matthew: Could do the OAM at the Ethernet level, but not VCCV Stewart: OK there is some work to be done. I.e., according to Matthew, what you have proposed does not match the MS-P= W architecture, and you cannot run end-to-end PW OAM, only Ethernet OAM. In both cases, stitching the PW traffic at the Ethernet level would work i= f and only if: - Ethernet PWs are the only PWs being deployed without the CW[[Sa= sha]] From my POV, RFC 7079 strongly suggest that this was the case even 5= .5 years ago. Since then I think the dominance of Ethernet PWs has only in= creased. - These Ethernet PWs are always single-homed (i.e., no dual-homin= g, no PW redundancy)[[Sasha]] H-VPLS can use PW redundancy as well I think= . What can be achieved with such a mechanism depends on what you are looki= ng for. - 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[[Sasha]] You can use Ethernet ser= vice OAM link trace for that. 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=EC 5 febbraio 2019 17:02 To: Italo Busi > Cc: pals@ietf.org; Shell Nakash >; Michael Gorokhovsky > 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 VP= LS as defined in Section 10 of RFC 4762 could be used without any changes: - T-PE1 and T-PE2 would treat S-PE 1 as their VPLS peer, but woul= d 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 pai= r of VPLS peers - MAC-based switching in all the PEs would be configured not to a= pply any policing on BUM traffic. If MAC learning can be turned off, it wo= uld 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 Etherne= t 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 -----Original Message----- From: Pals > On Behalf= Of Italo Busi Sent: Tuesday, February 5, 2019 4:02 PM To: 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 addres= sed 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 ar= e 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 (rec= ommending to enable the use of CW) seems sufficient As outlined by Dave in the meeting notes, more analysis needs to be done o= n: 1. the use cases where this function would be used e.g., m= obile transport? Ethernet enterprise services? data center interconnect? e= tc. 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 abo= ut these questions Thanks in advance Italo (on behalf of co-authors) _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this transmission in error, please inform us by e-mail, phone or fax, and then = delete the original and all copies thereof. __________________________________________________________________________= _ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB3828FD94804699BA5FE4F8179D6F0AM0PR03MB3828eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Italo,

Was your last questio= n was about migrating from a single-segment PW (without the CW) to the new= solution (whatever it can be) with minimal impact on traffic?<= /span>

This is a good questi= on and the answer is implementation-specific I think.

But generally speakin= g you could configure your H-VPLS first (with the PWs set up and all), and= then transfer your ACs in TP-1 and TP-2 from the original PW endpoints to= the VSI in these devices in a coordinated management action. Such a transfer would be, of course, traffic-affecting= , but, hopefully, the hits would be short enough. Not very complicated wit= h proper network management I think.

 

My 2c,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Al= exander.Vainshtein@ecitele.com

 

From: Alexander Vainshtein
Sent: Wednesday, February 6, 2019 6:09 PM
To: 'Italo Busi' <Italo.Busi@huawei.com>
Cc: pals@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; M= ichael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01

 

Italo,

Lots of thanks for a = prompt response.

Please see answers to= some of your questions inline below.

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Italo Busi <Italo.Busi@huawei.com>
Sent: Tuesday, February 5, 2019 7:37 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: pals@ietf.org; Shell Nakas= h <Shell.Nakash@ecitele.com= >; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01

 

Hi Sasha,<= /span>

 

Thanks for your comme= nt 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,[[Sa= sha]] It is definitely possible  is not something I really like/prefer/advocate<= /p>

 

If the option to stit= ch the PW traffic at the Ethernet level is acceptable, I would prefer foll= owing 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

[[Sasha]] My re= ading of the minutes (copied below for your convenience) is different:

Matthew: are you doing a label swap and addi= ng a CW added? 

Italo: Yes

Matthew:  The architecture do= esn't allow it.  You are really stitching the two PWs together, after= having gone to the Ethernet frame and then pushing the label stack with t= he CW.  This is in the architecture.  Change the draft to point to that.

Stewart: OK

Himanshu:  So this isn't a swi= tching PE, it’s a tear down and rebuild of the stack?

Stewa= rt: Yes, with end to end OAM.

Himan= shu: But everything terminates. It's not native, and not end to end if it = terminates.

Matth= ew: Could do the OAM at the Ethernet level, but not VCCV

Stewart: OK there is some work to be done.

I.e., according= to Matthew, what you have proposed does not match the MS-PW architecture,= and you cannot run end-to-end PW OAM, only Ethernet OAM.

 

In both cases, stitch= ing the PW traffic at the Ethernet level would work if and only if:

-=           Ethernet PWs are the only PWs being deployed without the CW[[Sasha]] From my POV, RFC 7079 st= rongly suggest that this was the case even 5.5 years ago. Since then I think the dominance of Ethernet PWs has only = increased.<= /p>

-=           These Ethernet PWs are always single-homed (i.e., no dual-homi= ng, no PW redundancy)[[Sasha]] = H-VPLS can use PW redundancy as well I think. What can be achieved with such a mechanism depends on what you are lookin= g for.

-=           It is acceptable to use Ethernet OAM instead of VCCV to monito= r 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[[Sasha]] You can use Ethernet service OAM link trace for that.

 

A side question would= also be how the network can be reconfigured without using the PW redundan= cy

 

Italo

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.co= m]
Sent: marted=EC 5 febbraio 2019 17:02
To: Italo Busi <Italo.B= usi@huawei.com>
Cc: pals@ietf.org; Shell Nakas= h <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 trie= s to solve admits a simple solution that is fully covered by existing stan= dards: the Hierarchical VPLS as defined in Section 10 of RFC 4762 could be used= without any changes:

-      &nb= sp;   T-PE1 and T-PE2 would tre= at S-PE 1 as their VPLS peer, but would not be aware of each other

-      &nb= sp;   S-PE1 would treat T-PE1 a= s a spoke peer and T-PE2 – as its core peer. It would do degenerated MAC-based switching between the two PWs it termi= nates (whatever comes in via one PW goes out via into the other one)<= /o:p>

-      &nb= sp;   T-PE1 and T-PE 2 will als= o do degenerated MAC-based switching

-      &nb= sp;   Usage of the CW would be = negotiated separately between each pair of VPLS peers

-      &nb= sp;   MAC-based switching in al= l the PEs would be configured not to apply any policing on BUM traffic. If= MAC learning can be turned off, it would also help

-      &nb= sp;   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-549= 266302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message-----
From: Pals <pals-bounces@ietf.= org> On Behalf Of Italo Busi
Sent: Tuesday, February 5, 2019 4:02 PM
To: pals@ietf.org
Subject: [Pals] Progressing draft-busi-pals-pw-cw-stitching-01<= /p>

 

During IETF 103, draft-busi-pals-pw-cw-stitching= -01 has been presented and discussed

 

We have received very valid technical comments t= hat we think can be addressed in the future versions of the draft

 

One of the main outstanding comment is about whe= ther the solution proposed in the draft is addressing a real need in deplo= yed networks

 

The draft is proposing a solution that could res= olve 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 t= o insert the CW because of hardware limitations and not T-PEs that are cap= able 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 a= nalysis needs to be done on:

        =         1. the use cases where this fun= ction would be used e.g., mobile transport? Ethernet enterprise services? = data center interconnect? etc.

        =         2. In these cases identified, h= ow likely would it be where the TPE would not be upgraded?

 

Since these issues are related to existing netwo= rk deployments and future/planned network upgrades, we would appreciate an= y input from operators about these questions

 

Thanks in advance

 

Italo (on behalf of co-authors)

 

_______________________________________________<= o:p>

Pals mailing list

Pals@ietf.org=

https://www.i= etf.org/mailman/listinfo/pals


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB3828FD94804699BA5FE4F8179D6F0AM0PR03MB3828eurp_-- From nobody Mon Feb 25 11:13:41 2019 Return-Path: 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 918B8130F55; Mon, 25 Feb 2019 11:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ti9t8qwrs7VE; Mon, 25 Feb 2019 11:13:38 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F011130F4D; Mon, 25 Feb 2019 11:13:38 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id v10so11881534qtp.8; Mon, 25 Feb 2019 11:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VuDEuEvdvI3XksmzzyQEIhmClZu6TL3fOAOPckcEjEs=; b=dDAYTVTIj2Qd5kd1k00LuBi3vLaCYM+paRlVcNqiV9R0VYrPPvYhOiZzS/AkmMrrc+ x+Kv3Na1IlISXZzseThBvERnr0or/WSiqec4esk+ADXJy9vBLlvuUX6gLik3xWdRnBAk VHIX3PMeWbJnEL8ggAJ1k0wrrk7O0Q2E1IXLgtRDmGQ0XZUHAR1EIvQZLnKYogjaeDKK +w9ZnkitXQ0yA+1iaJckeMX2ugM9R3gZURw7VWYt7I4pCuxiQCWl3/KaDY1ZPrwdQgDA 6YfHMQFS5S78i/2CR/0c0XekkGWDb+upquE2S21LqwKSg6gTLCMYR6PEn99rqTRsY9GF P1TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VuDEuEvdvI3XksmzzyQEIhmClZu6TL3fOAOPckcEjEs=; b=lFQRg+vLIeCg6cNRkmRKI1V9pbIOz47nAqU0ac3MViOeI1YZWKGIVpZqVgCe4MIlx2 reuDN18GPTqNbgItiOvHiDyAoADGY1vu67rJKeWDZn4nAsd2amzXjY0fD4R+lqydif6S sL9dmcrRqvIrGDj/vsuoJWTxty9PyJIAKrAuVmokiVztzqF/G2E6DiDfomko5/j6ZfX0 5NWWkXNBH6vo3aUx2S0CeljJTc6PvDZuud+9d/xZ2ac0T1nq//lIAfwN+bukz6g0fIDO vP4SwSIJ41cnyit1whFcj7U++/0Pa7C3wF8Riu71Gd35MY4hqZ+rPjcme8MbVzhd+Rjz NRXA== X-Gm-Message-State: AHQUAuasLRYquymRkUbrmbGtDg/myfqvN5v2MoexkvCNfBCDZs88LyBq +ESkE+7TbnWVrj6jey6pKkz5mwcrDyCOIAjtV18= X-Google-Smtp-Source: AHgI3IbcpnWMdiy8ybSOAbM9466CXR0pnrW0cW4LpHGDhD0XxP6dq/3niHkE5u4IlQOzuFUvRc/cgn07FIAfhZv/l34= X-Received: by 2002:ac8:38ba:: with SMTP id f55mr14862732qtc.192.1551122017603; Mon, 25 Feb 2019 11:13:37 -0800 (PST) MIME-Version: 1.0 References: <20190225140314.77DB0B81C75@rfc-editor.org> In-Reply-To: <20190225140314.77DB0B81C75@rfc-editor.org> From: "Andrew G. Malis" Date: Mon, 25 Feb 2019 14:13:26 -0500 Message-ID: To: RFC Errata System Cc: suresh@kaloom.com, terry.manderson@icann.org, "Giles Heron (giheron)" , nmalykh@ieee.org, "l2vpn@ietf.org" , pals@ietf.org, "BRUNGARD, DEBORAH A (ATTLABS)" , Loa Andersson , Eric C Rosen , Nabil Bitar Content-Type: multipart/alternative; boundary="000000000000dcd4e40582bcbc59" Archived-At: Subject: Re: [Pals] [Editorial Errata Reported] RFC4664 (5644) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 19:13:41 -0000 --000000000000dcd4e40582bcbc59 Content-Type: text/plain; charset="UTF-8" I agree with this errata; in addition, I would recommend changing the word "allocate" to "allocating". Cheers, Andy On Mon, Feb 25, 2019 at 9:03 AM RFC Errata System wrote: > The following errata report has been submitted for RFC4664, > "Framework for Layer 2 Virtual Private Networks (L2VPNs)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5644 > > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh > > Section: 3.4.3 > > Original Text > ------------- > Relative to the VPLS there are three different possibilities for > allocate functions to a device in such a position in the provider > network: > > > Corrected Text > -------------- > Relative to the VPLS there are two different possibilities for > allocate functions to a device in such a position in the provider > network: > > > Notes > ----- > > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4664 (draft-ietf-l2vpn-l2-framework-05) > -------------------------------------- > Title : Framework for Layer 2 Virtual Private Networks > (L2VPNs) > Publication Date : September 2006 > Author(s) : L. Andersson, Ed., E. Rosen, Ed. > Category : INFORMATIONAL > Source : Layer 2 Virtual Private Networks INT > Area : Internet > Stream : IETF > Verifying Party : IESG > > --000000000000dcd4e40582bcbc59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with this errata; in addition, I would recommend c= hanging the word "allocate" to "allocating".

Cheers,
Andy


On Mon, Feb 25, 2019 at= 9:03 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has= been submitted for RFC4664,
"Framework for Layer 2 Virtual Private Networks (L2VPNs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5644

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <nmalykh@ieee.org>

Section: 3.4.3

Original Text
-------------
=C2=A0 =C2=A0Relative to the VPLS there are three different possibilities f= or
=C2=A0 =C2=A0allocate functions to a device in such a position in the provi= der
=C2=A0 =C2=A0network:


Corrected Text
--------------
=C2=A0 =C2=A0Relative to the VPLS there are two different possibilities for=
=C2=A0 =C2=A0allocate functions to a device in such a position in the provi= der
=C2=A0 =C2=A0network:


Notes
-----


Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4664 (draft-ietf-l2vpn-l2-framework-05)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Framework for= Layer 2 Virtual Private Networks (L2VPNs)
Publication Date=C2=A0 =C2=A0 : September 2006
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: L. Andersson, Ed., E. R= osen, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INFORMATIONAL
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Layer 2 Virtual Pr= ivate Networks INT
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Internet
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

--000000000000dcd4e40582bcbc59-- From nobody Wed Feb 27 09:12:15 2019 Return-Path: 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 664A8130FBF; Wed, 27 Feb 2019 09:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xUz3I_F7VKlw; Wed, 27 Feb 2019 09:12:12 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706891289FA; Wed, 27 Feb 2019 09:12:11 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id n19so6572112wmi.1; Wed, 27 Feb 2019 09:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=kEyDX/vY1M42Xme/1HcewIeSyQPV6uVQmYj9BthtKF8=; b=XMJB+fxy9neziz6XVgSzJah5Yq0wUpZMrGlEoBx9hRfdvgkVBj3uV2PdntLznpb+VT FQG1A3YlMOSMJrRZNnLywwdXhcIVu60IxTxcAkgtTQUaffeEMc7+3uqjBAH9lj9U8Sy8 tNmtC+rs9YhJDctwwgGh8yDAcWVnS2bnYeoNQhQYUFQcsEOibMU4VIghDEWCTiRhdnmK 9g5kIUjRQB6yScshL0xRPvyqSIJmr4z7hOC72t3Nu/GfXA6pgDdPmndjMmIfYHZRK9Ih +uZFE8LObAe0iQqsZMScOXNTRUOw6ikXkFvnhuusrRdzQlJJ+uQWwPXJeC34W7PlNalE OTEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=kEyDX/vY1M42Xme/1HcewIeSyQPV6uVQmYj9BthtKF8=; b=s1k04uo/k3ZMbcvn1O+vPOi3xyNUY1wvw+5wNDNEvgasTm+1LSA3F5mfRwE8H6ZOkE 3xv6MmX7WVLQzqvC24tOC6XSbMjzWgWTKJZ8gKwvw/InX9XxoaLGWya6FZXLYhLTEmJP fA6ba1by/jZ/6p5UKtARuggA6WKJvnctgRjoAJRMEnUJrTjSPTmaApH9sEKL25nF6mdb I1WowGMLnQ8neGHi5l6Tf8JPLyD4o5dsgpHbe//xCmrEh269h6WcA9Ok/lK7jlPGAQoy d0DsT5sBIHFIuTaeq55G2ICTyIDtr83RgCE6isPsYr6DLi+PjD2F25tVGKcX6noFPmqt vf8g== X-Gm-Message-State: AHQUAuae3JQhDQmFMpuDURXCek4DeHmGKKo5QxHuGPLgJDBMUSGHPjLC fjkqoyqazjfAji9YV6JbhGI= X-Google-Smtp-Source: APXvYqxhgeTUe6y42vN/5l/7io4UB8cJhcmm6kU+CWYiuaLsbUFcGlfCSgrl/OcxtAHKQjEW5mudDg== X-Received: by 2002:a1c:7a03:: with SMTP id v3mr182166wmc.59.1551287529719; Wed, 27 Feb 2019 09:12:09 -0800 (PST) Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id d2sm16412441wrq.94.2019.02.27.09.12.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 09:12:08 -0800 (PST) To: "Andrew G. Malis" , RFC Errata System Cc: "l2vpn@ietf.org" , "Giles Heron (giheron)" , "BRUNGARD, DEBORAH A (ATTLABS)" , nmalykh@ieee.org, Nabil Bitar , pals@ietf.org, Loa Andersson , suresh@kaloom.com, Eric C Rosen , terry.manderson@icann.org References: <20190225140314.77DB0B81C75@rfc-editor.org> From: Stewart Bryant Message-ID: Date: Wed, 27 Feb 2019 17:12:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C2399025D7820D251608C5D8" Content-Language: en-GB Archived-At: Subject: Re: [Pals] [Editorial Errata Reported] RFC4664 (5644) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 17:12:14 -0000 This is a multi-part message in MIME format. --------------C2399025D7820D251608C5D8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes, but not for anything beyond editorial, fix in next revision. No one will make an implementation error and the RFC is nearly 13 years and this has not been picked up before. - Stewart On 25/02/2019 19:13, Andrew G. Malis wrote: > I agree with this errata; in addition, I would recommend changing the > word "allocate" to "allocating". > > Cheers, > Andy > > > On Mon, Feb 25, 2019 at 9:03 AM RFC Errata System > > wrote: > > The following errata report has been submitted for RFC4664, > "Framework for Layer 2 Virtual Private Networks (L2VPNs)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5644 > > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh > > > Section: 3.4.3 > > Original Text > ------------- >    Relative to the VPLS there are three different possibilities for >    allocate functions to a device in such a position in the provider >    network: > > > Corrected Text > -------------- >    Relative to the VPLS there are two different possibilities for >    allocate functions to a device in such a position in the provider >    network: > > > Notes > ----- > > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4664 (draft-ietf-l2vpn-l2-framework-05) > -------------------------------------- > Title               : Framework for Layer 2 Virtual Private > Networks (L2VPNs) > Publication Date    : September 2006 > Author(s)           : L. Andersson, Ed., E. Rosen, Ed. > Category            : INFORMATIONAL > Source              : Layer 2 Virtual Private Networks INT > Area                : Internet > Stream              : IETF > Verifying Party     : IESG > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --------------C2399025D7820D251608C5D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Yes, but not for anything beyond editorial, fix in next revision.

No one will make an implementation error and the RFC is nearly 13 years and this has not been picked up before.

- Stewart


On 25/02/2019 19:13, Andrew G. Malis wrote:
I agree with this errata; in addition, I would recommend changing the word "allocate" to "allocating".

Cheers,
Andy


On Mon, Feb 25, 2019 at 9:03 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitted for RFC4664,
"Framework for Layer 2 Virtual Private Networks (L2VPNs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5644

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <nmalykh@ieee.org>

Section: 3.4.3

Original Text
-------------
   Relative to the VPLS there are three different possibilities for
   allocate functions to a device in such a position in the provider
   network:


Corrected Text
--------------
   Relative to the VPLS there are two different possibilities for
   allocate functions to a device in such a position in the provider
   network:


Notes
-----


Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party 
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4664 (draft-ietf-l2vpn-l2-framework-05)
--------------------------------------
Title               : Framework for Layer 2 Virtual Private Networks (L2VPNs)
Publication Date    : September 2006
Author(s)           : L. Andersson, Ed., E. Rosen, Ed.
Category            : INFORMATIONAL
Source              : Layer 2 Virtual Private Networks INT
Area                : Internet
Stream              : IETF
Verifying Party     : IESG


_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals
--------------C2399025D7820D251608C5D8--