Re: [Idr] status - incremental 4/8/2020 -
Linda Dunbar <linda.dunbar@futurewei.com> Wed, 08 April 2020 13:56 UTC
Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9E43A095B; Wed, 8 Apr 2020 06:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 nUX__Tmr2DH6; Wed, 8 Apr 2020 06:56:56 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2129.outbound.protection.outlook.com [40.107.244.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 66CF73A1012; Wed, 8 Apr 2020 06:55:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CQY7CB9Ze4Rl32JtanWF0r5iH2df1NPv97Zfx8Z7EEyX0dxqjcbi9Fsd8TFGm6OzyUvQTWf8COrHRtpxvjb2o1KZ0ZOKl+Exc1oh+6gi4xzfySvRvK/EKt3cEnSh6DH0bFoqRlhUu+T0REI6tbK7g4hnm4452kwIoZVPye1QbD8CUSEBE+Qr4w/byDfoJIiAgGUxKhLWTu4LQ18J28HZM/jhTkBRdZF6JSeWUmV+bEVG9Qkp7V+orARsqONHo1GnxV/pyNnerxNaFYhMxsG0R7A4pTev7onx3B+I2YHeZ+hEF0i6mncIdBhvhMoPF0THDVITpbNSLlyBqZwNQNjmoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IcH4rUjhu6QGtUcWLEaKexAk35uVKlwpOleQYfXbM2k=; b=cPfb2QTr8nUN5D4X054iYXg4JhPrPqhwfE7iK2VOapWYBZkqFVpJtfpqwEGA55X4ahOrddOG7U7onkxRaSxfe00AMKnoArBVsOfd54w96/A2dryca+iq1J7kl53QKMxG6a4Cf7vQLccK0fkB4wR67WNwvKlXGzZI+lfPuqLl6hPSIVpnGD4uNhH79KSBuJA4OVmQn4FpN3i2PjJCrhexVlUjkChdsPAZ5oA9ijmkXPuQfSF7MmpecIhH+b2CZPhEtSkBiVevWZQg0X5axqPC1ORfH1ePanjoqu2Kj7sgPAKGT4t3dPQ74QlpX+616trGYqWWTwYBwaWZl/SD4AyBeA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IcH4rUjhu6QGtUcWLEaKexAk35uVKlwpOleQYfXbM2k=; b=je0hMpEcnVVi8CbkFJ7mzG5gy8zZN4qnyFR+QJ3uMkSmKkLtcdJj29W5MtVjJyasPB867/aaNkCDKK2GPGFz7Yl//8x/MuWLHnvKkt5qc7jslE60zn2APWJdoPFzIUS6tA+rx+W3EC6RRzAJfX1w/PiOT7zLvAna48DiFtVyaYI=
Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB1903.namprd13.prod.outlook.com (2603:10b6:301:2d::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Wed, 8 Apr 2020 13:55:27 +0000
Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945%3]) with mapi id 15.20.2900.012; Wed, 8 Apr 2020 13:55:26 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
CC: "draft-hujun-idr-bgp-ipsec@ietf.org" <draft-hujun-idr-bgp-ipsec@ietf.org>
Thread-Topic: [Idr] status - incremental 4/8/2020 -
Thread-Index: AdYNokgRyeOIrfLpRmOFOKAsBaX81gAClIpw
Date: Wed, 08 Apr 2020 13:55:26 +0000
Message-ID: <MWHPR1301MB209641BC33D7C9A62CDCA6C585C00@MWHPR1301MB2096.namprd13.prod.outlook.com>
References: <008901d60da2$74031370$5c093a50$@ndzh.com>
In-Reply-To: <008901d60da2$74031370$5c093a50$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com;
x-originating-ip: [72.180.73.64]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0ebcddc6-fa21-49b5-1fde-08d7dbc47dd0
x-ms-traffictypediagnostic: MWHPR1301MB1903:
x-microsoft-antispam-prvs: <MWHPR1301MB190337AB4BE93F5300250B1E85C00@MWHPR1301MB1903.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1301MB2096.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(346002)(136003)(39840400004)(396003)(376002)(366004)(44832011)(55016002)(2906002)(66446008)(33656002)(9686003)(8676002)(66556008)(4326008)(86362001)(64756008)(71200400001)(66476007)(478600001)(5660300002)(6506007)(66946007)(53546011)(76116006)(7696005)(81156014)(99936003)(26005)(81166007)(8936002)(186003)(316002)(52536014)(66616009)(110136005); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mlFD7+uyHlUzB2jYuLBvQbNcx9BFZjDhUIjSwXIHE5+lPD7Q87KuO61Ood82PsIZKz5XWDrkmrcgJ/xhI5R6LXg0jL8oZzZhwWCNB542d3jDJ6jf2OVRCS+Ev9z3zmVpBjNkbVLyo18FsqUo+C/pcCvcEcUmsLmZe5c3Oc6xTXWd7/sz/f3AxFUseLaKsMWxkoJYLUWudj4I0HFSe7lLxu8n0NLYjgU/lSvspboreE7xxsxCMasI+P8CGFgBcPzX3qeSbBnJLynfaEUMm0OVRglJI707BA5WPjzxfRM9d7Sl46FFBlfTqmqderHn32oc+3rvNbV8pUkv6ppx96o7OE4QB9KZ0T1oWOuqYIr+oAVjC6pEevL3nWmHVYGZ4NZ+GtopXoygzekyLM+5gFAvIT5P+Q7+rFACR2gaVo5IeBuwdyUJjgIihZRvmiIWyVtyOz1P0koy9znx1eC7FMiDpzRtF80s9GzFxTMiER2Gbfyl9IauVq6FXubhFoQc8+mtVERWVxv0PsAqPw2Q89SOsw==
x-ms-exchange-antispam-messagedata: ryHLSsB1MWT2Q9m21F/cu/XW1wBJbXSj9Som6/qlDzhL5XjD18BV8mcoef/sOE91CSOkU8rzm3wuFShZ//XESNuCFDF2Gjjzrg0qjnE6w1V/mvk4Yi7bCv3d3DuNifwkh4i1u596Buv+m90a1/hFag==
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_004_MWHPR1301MB209641BC33D7C9A62CDCA6C585C00MWHPR1301MB2096_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ebcddc6-fa21-49b5-1fde-08d7dbc47dd0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 13:55:26.4630 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ULm9bhi7eepcT37+q0iRWOOPdc67/ZcKYXJBbdzh2N4S8+zCZRiOuuT0cmL8tCVlCZPtnayl5n7jS84Xqpf1qw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB1903
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ulMjJLPFlNGUGQxOwr95RO93GH4>
Subject: Re: [Idr] status - incremental 4/8/2020 -
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 13:57:00 -0000
For the Draft-hujun-idr-bgp-ipsec & draft-hujun-idr-bgp-ipsec-transport-mode waiting for WG adoption, I hope the authors can answer my questions (attached) which were sent last week. In particular: 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers? 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKEv2 with the speaker without any configuration from the administer? If Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the BGP update from the C? 2. How does the BGP UPDATE ease the IPsec configuration? Does it ease the configuration on the BGP UPDATE speaker? Or does it ease the configuration of the receiver? 3. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is there still "Private Routing Instances"? 1. On Page 3, the draft states that only "Local Tunnel Endpoint address, Public Routing Instance and CHILD SA traffic selector address range" are advertised by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the node? Or can be a specific Ingress or egress port of the node sending out the BGP UPDATE? Thank you very much. Linda Dunbar From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares Sent: Wednesday, April 8, 2020 7:37 AM To: idr@ietf.org Subject: [Idr] status - incremental 4/8/2020 - IDR WG: A little status to read with your coffee this morning. We have an interim at 13:00 UTC (9:00 EDT, 6:00 PDT, 21:00 Bejing time) Please let me know if I've missed any updates. Cheers, Sue --------- At IESG in IETF LC 1) draft-ietf-idr-rfc5575bis-19.txt - Shepherd: John Scudder Status: IETF LC ended, IESG telechat: 4/15 IESG Publication request: 7/9/2019 2 AD Reviews [8/2-9/10/2019, [1/17-1/23/2020] 2) draft-ietf-idr-bgp-ls-segment-routing-msd-08.txt [Shepherd: Susan Hares] Status: 3rd round of AD revisions IESG Publication requested: 10/15/2019 IETF WG LC: 6 days -------------- AD review - authors need to respond 1) draft-ietf-idr-tunnel-encaps-14<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-tunnel-encaps%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C435c81989b484cc4b36e08d7dbb9a0fd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637219462629089078&sdata=bbY8QsY3BjyYZ3kRMAAyotniLSklUtXjskdGXA7FasY%3D&reserved=0> - sent to IESG [Waiting 47 days] 2) draft-ietf-idr-capabilities-registry-change-05.txt [Waiting 57 days] ------------ WG past WG LC - stuck waiting for implementation reports on wiki [reported to have 2 implementations, but no details on wiki] 1) draft-ietf-idr-ext-opt-param 2) draft-idr-eag-distribution-09.txt --------- Drafts stuck post WG LC - waiting for minor edits 1) draft-ietf-idr-rfc8203bis.05.txt - ---- Flow specification drafts in WG LC 1) Draft-ietf-idr-flow-spec-v6-10.txt Status: restarted [4/8 to 4/22] Status: IESG desires, but is it ready? Needed: implementation reports 2) draft-ietf-idr-bgp-flowspec-oid-11<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-bgp-flowspec-oid%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C435c81989b484cc4b36e08d7dbb9a0fd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637219462629089078&sdata=1FHbWhfNi%2FZMqmS3xeslLMVZH3rgYUyxgLv%2FJMS4Wxg%3D&reserved=0> Status: 3/13/ to 4/13 Status: light response, please comment Authors: Please fill out implementation report ----------- WG Adoption calls: 1) Draft-hujun-idr-bgp-ipsec WG adoption: 3/30-4/13 Shepherd: Susan Hares Comment: only 1 response, heading toward "no consensus" 2) draft-hujun-idr-bgp-ipsec-transport-mode WG Adoption: 3/30 - 4/13 Shepherd: Susan Hares Comment: only 1 response, heading toward "no consensus" 3) draft-li-idr-sr-policy-path-mtu-03.txt WG adoption: 3/30 - 4/13 Shepherd: Susan Hares Comment: Positive response: Heading toward WG Adoption Request for input: ---------------------- draft-scharf-tcpm-yang-tcp-04 Proposed WG LC drafts for flow-specification that were on hold: ------------------------------------------- [Authors should contact chairs] 1) draft-ietf-idr-flowspec-interfaceset-05 - WG notes indicated this might go ahead without flow-specification v2 2) draft-ietf-idr-flowspec-path-redirect-10 - WG discussion needs to occur on whether flowspecification Proposed WG LCs (3/30 and 4/8) ---------------- 1) draft-ietf-idr-bgp-open-policy-08 - on hold pending revision -09 2) draft-ietf-idr-flowspec-l2vpn-13 - in slides for 4/8 Proposed Adoption calls ----------------------- draft-cl-idr-bgp-ext-com-registry-udpate-00.txt
--- Begin Message ---Jun, Need a few clarify questions for your draft. 1. Does draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers? 1. Does receiving the IPsec BGP UPDATE triggers a node to start the IKEv2 with the speaker without any configuration from the administer? If Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the BGP update from the C? 2. How does the BGP UPDATE ease the IPsec configuration? Does it ease the configuration on the BGP UPDATE speaker? Or does it ease the configuration of the receiver? 3. How to differentiate Public Routing Instances? If the payload packet within the IPsec tunnel are simple IP forwarding, is there still "Private Routing Instances"? 1. On Page 3, the draft states that only "Local Tunnel Endpoint address, Public Routing Instance and CHILD SA traffic selector address range" are advertised by the BGP. Is the Local Tunnel Endpoint address same as the LOOPBACK address of the node? Or can be a specific Ingress or egress port of the node sending out the BGP UPDATE? Thank you very much. Linda Dunbar From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares Sent: Monday, March 30, 2020 7:07 AM To: 'IDR List' <idr@ietf.org> Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020 This begins a 2 week WG adoption call for two drafts BGP provisioned IPSEC infrastructure 1) draft-hujun-idr-bgp-ipsec-02.txt: BGP Provisioned IPSEC Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb1e68b21c294ff7e40f08d7d4a2e5e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637211668440594288&sdata=HRHfVUUOy0a1ofnIzfTM4zsBqzZCGEhyMEopPdtEdyI%3D&reserved=0> 2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt: BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec-transport-mode/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb1e68b21c294ff7e40f08d7d4a2e5e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637211668440604245&sdata=XROXZN5YTy5GQEToYyAkFNHx71%2B%2FXnln1QJjMzeRQ6I%3D&reserved=0> These drafts were presented at IETF 104 and IETF 105. At IETF 105, there was a detailed discussion on the security issues. After IETF 105, the author modified his draft to take care of the Issues mentioned. Discussion during the WG Adoption should examine: 1) Has this draft addressed the necessary security issues to be adopted as IDR WG draft? 2) Is this useful generic IPSEC functionality for networks? The EVPN related to IPSEC continues in BESS. This draft is considered here as a general feature. 3) Are there any deployments of this draft? Stay safe and healthy... Sue--- End Message ---
- [Idr] status - incremental 4/8/2020 - Susan Hares
- Re: [Idr] status - incremental 4/8/2020 - Acee Lindem (acee)
- Re: [Idr] status - incremental 4/8/2020 - Linda Dunbar
- Re: [Idr] status - incremental 4/8/2020 - Susan Hares
- Re: [Idr] status - incremental 4/8/2020 - Jeff Tantsura