Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Wed, 19 December 2018 07:54 UTC

Return-Path: <jorge.rabadan@nokia.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D292130DEB; Tue, 18 Dec 2018 23:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.966
X-Spam-Level:
X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 UIiXnIoxqRzF; Tue, 18 Dec 2018 23:54:42 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::704]) (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 CB84B12426A; Tue, 18 Dec 2018 23:54:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ptiCKrAzKU+J4E80MNmhM3W9TqbTRPBncndfPwBhkd0=; b=JlVnDPDhWODGNIcvkGSs/KszUnZq69RQTeCU0b08x0h4TF/JLvXp+faKwOvER8s2mq0ExOIun0U4Bjtc20UU+uvwV+OEW34FfciKlQ71/n+GhAYUu1c8JwU2z6yQ8DcIfM6pewCYwuu7vd70oAijRN+3mJ/Z13U9EsxesfiztEY=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB5507.eurprd07.prod.outlook.com (20.178.23.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Wed, 19 Dec 2018 07:54:35 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::a043:32e8:b786:3486]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::a043:32e8:b786:3486%4]) with mapi id 15.20.1446.015; Wed, 19 Dec 2018 07:54:35 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Linda Dunbar <ldunbar@huawei.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "draft-ietf-bess-evpn-vpls-seamless-integ.all@ietf.org" <draft-ietf-bess-evpn-vpls-seamless-integ.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05
Thread-Index: AQHUlykNcC10id7bbE+GnprsTv+XNaWFwpoA
Date: Wed, 19 Dec 2018 07:54:35 +0000
Message-ID: <B53FB0F5-801B-48FD-A4D0-18F6AF6DC173@nokia.com>
References: <154517556254.5530.14577483027370675798@ietfa.amsl.com>
In-Reply-To: <154517556254.5530.14577483027370675798@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.14.0.181208
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [88.14.53.100]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5507; 6:DvCU+LPpFhwHRlzF0UCB90ENXduBywRdbf8zBCAIy65VcC7ZY0LDgf+z9bz0SfE/QbvLa22Wh3vcuzQFCdatQJk2UZkg7YUL9Z5H+0zpvlgM0sEZUwJSZ3EbDm1ussCrmwowatclfK/KQHfHFQHEuYv/q4UPqFizPl4mGWUQGK7R4kd0FrAlhQqohBhj2Hgg09JrAe5bzNCHDzlyH9gAhbWnilGR+AnL0MH+AYYDkoEkHIZaj5hDhoRB5di3kwpYQE2B2XTHQM/E2q9gsccErdR7Hed+ugO57o+RZiEe9sdeENJbkFblhBoHlu/pDJzqHdXHxK/cFFY1dTM6gyKMDd9JfyIPShnLIr353+SSVarYmwxX7geMtL3fPKmZrh0d+auBCmXC9kYzdPJpk+KL/55gj4d3A1a63egBBSMvdB4McQryqHq67RSDx+fzUJf9d690S+1Ux7J5r3P8vX9Fiw==; 5:FesiajzdsJ027OHgeMAI8nfSpCHEUmLmGLr9gpm8/scM8LMuwLtbsOFUw6qHeuQTgNTGpRxske2wIEDuzk7KVcYe7FLBnntMocGBqEjNeP7fNFzE8NRF8w+HWtrwrLHIXm45pblEjT1cCXlty1fkotASDMwTAe0k5mEeV/AZlXE=; 7:L47M3HIDuI3QPQsKS7YomXg4lladlKiOZhuDcuBlqhKzRmUz4vmrtxodfuuUXVsBqaGU/mlnxCGe8dpAVQ4PLaLSVdJPmF4aYhBK/ea8yWmmpnUtSMfGsbD2vLkLldcpMEhWJ78QSAAh2iyBfK9S6A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b5dbc54c-cdb0-4eb8-af8f-08d66587383b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB5507;
x-ms-traffictypediagnostic: AM0PR07MB5507:
x-microsoft-antispam-prvs: <AM0PR07MB5507D7F7288B9F0E576B99B4F7BE0@AM0PR07MB5507.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(11241501185)(806100)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231475)(944501520)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5507; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5507;
x-forefront-prvs: 0891BC3F3D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(366004)(39860400002)(13464003)(189003)(199004)(6512007)(36756003)(82746002)(106356001)(53936002)(105586002)(68736007)(6506007)(53546011)(102836004)(26005)(99286004)(76176011)(58126008)(110136005)(316002)(6116002)(3846002)(86362001)(2906002)(66066001)(54906003)(186003)(33656002)(81166006)(81156014)(97736004)(8936002)(256004)(8676002)(25786009)(229853002)(6486002)(7736002)(305945005)(5660300001)(2501003)(486006)(446003)(11346002)(476003)(2616005)(14454004)(478600001)(6436002)(345774005)(83716004)(71190400001)(71200400001)(4326008)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5507; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: EP6CWxQtyq54ldxz8w6Q+FBo/z46/DHEVGTD0+e9AwU7uSklrQj7Q7fNZ0AT2bvkgblEKr9Dv5GM75YUb0zETOmI9rnFQbvGXPSdrcyqZ7PzrcY7NEIzSu/ez90N0pmqyiGvfEV9fR7YXgTgO7CVLpwjIpgULDHLQSp5ZTO4XIRS5saNVeGG2sKKS6ZWoyfPf/XJYB5H3PPJEgzgkxrQjM40t/il3+/1dGspZPeas+5hxm2ohO+Fu3U02/KWgK6dy/t2AabFEtREbT5TR/5EEdyRIq8b0sMF8+v1xyBrR8PHof2hjt9jSyDLchK+aaI3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1A65C03B9181F840BC30AC8CAB4635CC@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b5dbc54c-cdb0-4eb8-af8f-08d66587383b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 07:54:35.6836 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5507
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/E7wcPEPFcrdPPLxZefWKOvGDw1w>
Subject: Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 07:54:45 -0000

Linda,

Thank you for reviewing. 

I think the document has to be Standards Track. Especially for the PEs that support both VPLS _and_ EVPN, the procedures described must be consistent in all the PEs that participate in the seamless integration, otherwise there could be loops or blackholes. Also we are defining procedures to allow PWs and EVPN destinations in the same split-horizon-group. Although there are no changes in BGP or LDP, there are changes in the EVPN procedures. 

"Page 8 Section 3.2: why set up the PW if keep it operationally down?"

The main reason is to avoid having to re-establish the PW if the IMET route is withdrawn. In that case the PW provides a fast backup path if the EVPN destination becomes unavailable. Note this is the case also for manual FEC128 PWs. If the two PEs can successfully establish a PW, there is no reason to not do it and have it ready in case the EVPN connection becomes unavailable. 

If the draft is used for migration purposes only, after the PEs are migrated, the VPLS AD and PW configuration can be removed to release resources.

Thank you.
Jorge


-----Original Message-----
From: Linda Dunbar <ldunbar@huawei.com>
Date: Wednesday, December 19, 2018 at 12:26 AM
To: "ops-dir@ietf.org" <ops-dir@ietf.org>
Cc: "draft-ietf-bess-evpn-vpls-seamless-integ.all@ietf.org" <draft-ietf-bess-evpn-vpls-seamless-integ.all@ietf.org>rg>, "ietf@ietf.org" <ietf@ietf.org>rg>, "bess@ietf.org" <bess@ietf.org>
Subject: Opsdir last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05
Resent-From: <alias-bounces@ietf.org>
Resent-To: <sajassi@cisco.com>om>, <ssalam@cisco.com>om>, <nick.delregno@verizon.com>om>, <jorge.rabadan@nokia.com>om>, <matthew.bocci@nokia.com>om>, <stephane.litkowski@orange.com>om>, <mankamis@cisco.com>om>, <martin.vigoureux@nokia.com>om>, <db3546@att.com>om>, <aretana.ietf@gmail.com>om>, Matthew Bocci <matthew.bocci@nokia.com>
Resent-Date: Wednesday, December 19, 2018 at 12:26 AM

    Reviewer: Linda Dunbar
    Review result: Ready
    
    Reviewer: Linda Dunbar
    Review result: Ready with comments
    
    I have reviewed this document as part of the Operational directorate's
    ongoing effort to review all IETF documents being processed by the IESG.  These
    comments were written with the intent of improving the operational aspects of
    the IETF drafts. Comments that are not addressed in last call may be included
    in AD reviews during the IESG review.  Document editors and WG chairs should
    treat these comments just like any other last call comments.
    
    The draft describes the procedures for EVPN PEs to handle traffic from VPLS
    PEs, to enable smooth transition from VPLS network to EVPN network. The
    procedures are written very clear, (although I am not sure why it is a Standard
    Track document as the document is mainly in describing the procedures of PEs
    that support both EVPN & VPLS).
    
    Question to the authors:
    
    Page 8 Section 3.2: why set up the PW if keep it operationally down?
    
    Best Regards,
    Linda Dunbar