Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Mon, 22 July 2019 15:15 UTC

Return-Path: <sajassi@cisco.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 E0FFC120329; Mon, 22 Jul 2019 08:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.399
X-Spam-Level:
X-Spam-Status: No, score=-14.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Dal/Lp82; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oV2vU1Gr
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 qi5HCHFAUHSI; Mon, 22 Jul 2019 08:15:36 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6AF12031D; Mon, 22 Jul 2019 08:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65013; q=dns/txt; s=iport; t=1563808536; x=1565018136; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rU2KH3sX/wfg85Q4jkBNaIHt01TjqAhPTocx/yha6oY=; b=Dal/Lp821yz1hu026gG/tCN5FyrH/Gn/L4FVt7gF43qX9VOmwc+idzWE ZmFyGnt47U/CRDq7IPziLZW19mvfR22t2dYJFqPFZq26xp01s8qJHxMbp 99th1V4aBaAp7eCcMhEeCs2uL8lLEdsD4ZfNql93vFRZnYh3PW8ICZive Q=;
IronPort-PHdr: 9a23:qC0iORPeQLR0/0RVFeUl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBjgJfzjdDc7NM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAABz0jVd/4YNJK1mGQEBAQEBAQEBAQEBAQcBAQEBAQGBVQIBAQEBAQsBgRQvUANtVSAECyqEHYFfgWgDjX6CW36WUoEugSQDVAkBAQEMAQEiCwIBAYEFXYJeAheCTCM2Bw4BAwEBBAEBAgEGbYUeDIVKAQEBAQMSCAkdAQEsCwEPAgEGAg4DAwEBASEBAgQDAgICMBQJCAIEAQ0FIoJ7BAEBgR1NAx0BAgyPSZBgAoE4iGBxgTKCeQEBBYEGASsBAwIOQYJ8AxWCEwMGgTQBi14XgX+BEScfghcHLj6CYQEBAgEBFoFeCQ0JglUygiaMNCGCI4R+I4hIjgYJAoIZhliIcIREG4ItL4Z2hAyKLIoKgyuBMYYXjDmDTwIEAgQFAg4BAQWBVwcqDYFLcBU7KgGCQROCCyQMFxSDOoUUhQgBNnIBAQEBgSWOAm8BAQ
X-IronPort-AV: E=Sophos;i="5.64,295,1559520000"; d="scan'208,217";a="589450157"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2019 15:15:34 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x6MFFYBv005241 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2019 15:15:34 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 10:15:33 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 10:15:33 -0500
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 22 Jul 2019 10:15:32 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JA0IrPXES55DftgJcnnFfBbP8jPghxK/MGwXm4fRj+mELa7BaEXB/q5VTKF0hdK/2YvA7PReOpTrQOR1tkVQq9irjSY3wucXh0HMStt1jTVSh0SuQM7HX5ZDBOABWfm/XtOu/mcO9JmUiN0vA++7VLcu3/D7TGHqOhb4t7K/y/czPaw4J322TySQU2htHlJpGVKjAYnDRLPz10BUcpkjNgYn//4qUaoKChJNRYnG9ZQVeDwhAulK07ECmwcQ01cU3D4V+0JVPH7TRl3Y/ykG3dJhKL6eQVGiGDNeIsNwA4b+3PMJ0fodxXz1piWPkoWsLylyVL4KRT5kcNBeJlPCGg==
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=rU2KH3sX/wfg85Q4jkBNaIHt01TjqAhPTocx/yha6oY=; b=Tar3WTvM6WSbTinTI8oyc+EjjtQINlUSPctN65I8pI+QdKM+lQPfbMpwB3ItbFh9QGBqaeL1NzDSZxZilFDbz9SqjYYsAz1zScXP/zxJ5A9wDP3UksUp40l58j3iAMzpitcsmQmBXOFlbyh1Z15yzi3ypZnhVlGF8xYwOLxkSdYhZCxVLgd66yogUszMXz//58cWTXOsCjANp5J48IAJ56vQ4swvCx2OKxSzdLVzYy7289G0zca3LJtbbm3pbkaEOZ+8Tvw4Pk2aSLsgsuhbO/ADoePKI25yVPRJheTmmk2zHB0HEfCyWBE0jZMmdLpjs3B7gqpsD5WbC10fC0wYGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rU2KH3sX/wfg85Q4jkBNaIHt01TjqAhPTocx/yha6oY=; b=oV2vU1GrLVc3BxvcgqNnyQtOgWrTif2AlUXG3Bqf8kJprK1BC0IkugyWYH94CR7f1HshTa1BMuRpbtwMYYn4zwMEkORAeqFC1UJq2rZX5kBGFIzOSDgYcZYw1yNZPFy54w94EvnM29xIuaHxwNfT5NDUsZsxciCut8nmKqsAHsk=
Received: from BYAPR11MB3703.namprd11.prod.outlook.com (20.178.237.220) by BYAPR11MB3157.namprd11.prod.outlook.com (20.177.126.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 15:15:31 +0000
Received: from BYAPR11MB3703.namprd11.prod.outlook.com ([fe80::4ca0:1d8d:a720:2ca9]) by BYAPR11MB3703.namprd11.prod.outlook.com ([fe80::4ca0:1d8d:a720:2ca9%5]) with mapi id 15.20.2094.013; Mon, 22 Jul 2019 15:15:31 +0000
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Susan Hares <shares@ndzh.com>, 'Linda Dunbar' <linda.dunbar@futurewei.com>, 'Keyur Patel' <keyur@arrcus.com>, "Acee Lindem (acee)" <acee@cisco.com>, 'John Scudder' <jgs@juniper.net>
CC: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, 'Robert Raszuk' <robert@raszuk.net>
Thread-Topic: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Thread-Index: AdUfzDTwk+JWx4NrTbCw24feqIEcxQADfhQAAABU8AAALY6XEAAB/DuAAADA04AAGnlYgAAHy0SAAANKonD//6TtAIAAeiGA//+V+QCAAGyrAIA+OnuA//+Jp6CAAO+7AP//j9eA
Date: Mon, 22 Jul 2019 15:15:31 +0000
Message-ID: <341AB55A-B9A6-473C-A345-3111D021DB1B@cisco.com>
References: <MN2PR13MB358247036D97F6620E2CB987A9130@MN2PR13MB3582.namprd13.prod.outlook.com> <234E41A5-F754-4630-B73C-8A9D52E44198@juniper.net> <6691B6FF-E9F5-4E9B-8D91-E8371993EDB5@juniper.net> <MN2PR13MB35826173FB5AC8D019497438A9ED0@MN2PR13MB3582.namprd13.prod.outlook.com> <5E89EE56-8852-4A1C-B072-EFE15ADA2618@juniper.net> <9E64708F-5E78-422C-8339-3447529BABB4@arrcus.com> <CAOj+MMFVhNFUnAe-QxyWHX65PY=VQmCK0N5aOcx=5nAApX5z4g@mail.gmail.com> <68538D45-E8CD-4FDA-ABA4-BEC4A7586410@juniper.net> <MN2PR13MB3582C58B3C84105B43191547A9EC0@MN2PR13MB3582.namprd13.prod.outlook.com> <F0F388CC-9B96-4E35-8E20-72A3B0C75347@arrcus.com> <900E9356-CB87-4148-BAE9-238A6C3A3230@juniper.net> <20D8F76F-093A-48E3-873C-90720EAD5C51@arrcus.com> <12DEE829-3FAD-4E05-B5AF-EF61046CD5D6@cisco.com> <5460E5F7-8F8A-4F06-9494-C25D11E0BAFF@arrcus.com> <MN2PR13MB358211D57A510E22ACEC07DF85C40@MN2PR13MB3582.namprd13.prod.outlook.com> <003801d5409d$b59b88d0$20d29a70$@ndzh.com>
In-Reply-To: <003801d5409d$b59b88d0$20d29a70$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sajassi@cisco.com;
x-originating-ip: [2001:420:c0c8:1004::660]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6dd6b933-6ee3-463f-4abe-08d70eb76fb4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3157;
x-ms-traffictypediagnostic: BYAPR11MB3157:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB31571483F38D174384B98655B0C40@BYAPR11MB3157.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(376002)(396003)(346002)(366004)(136003)(39860400002)(189003)(199004)(66574012)(71200400001)(30864003)(71190400001)(6486002)(6512007)(54906003)(316002)(58126008)(110136005)(36756003)(68736007)(8936002)(33656002)(6436002)(236005)(6306002)(53946003)(66446008)(8676002)(64756008)(54896002)(4326008)(5660300002)(1941001)(99286004)(7736002)(76116006)(66556008)(66476007)(66946007)(11346002)(446003)(46003)(2906002)(6116002)(256004)(76176011)(14444005)(86362001)(606006)(6246003)(186003)(2616005)(476003)(53936002)(229853002)(102836004)(25786009)(478600001)(81166006)(81156014)(966005)(53546011)(6506007)(486006)(14454004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3157; H:BYAPR11MB3703.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: TzmawyoagX7csnk78YKOC83Q3AviEXb08mUGJP8FK8oGZDZF8L/9R4oFbcvyPCnmxcuSA5s8uFRIYrYf+C453XexS/5WQgUIvxRjxiZwzsuQpNny8AdUivmorK6XxVUQoIY2Iq6ZdZtg8fDhSrVuFKbcnfMsh7Q20MGd7N/lYyy7U8ox/Jr4ll1gjdrCoBrbAJepX5J3AU9vMpaZlyG6oxB6oHF6EjObi0q2U0N6CEbWN9/xJ7g0XrqQ/pUrSak+/T58UFZRxvzP33ddZIqPneOOUDvvLuC/EMHwWIJyFpOuf0CJHvx0Qy3tZwteRCO+i08hjl9Nu3nt/Ojqy01Eu1BLykEUddWMV3z3g7lLIv+etYVenP8zGoyLANAB7wXwQ1HAagbFV4iHXnGyVBqheLyrRjoTuUPHnGiWp6QLUl0=
Content-Type: multipart/alternative; boundary="_000_341AB55AB9A6473CA3453111D021DB1Bciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6dd6b933-6ee3-463f-4abe-08d70eb76fb4
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 15:15:31.0476 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sajassi@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3157
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bkgDHIEwxK91gKChG_iFWZn501w>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
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: Mon, 22 Jul 2019 15:15:45 -0000

+1

-Ali

From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
Date: Monday, July 22, 2019 at 7:59 AM
To: 'Linda Dunbar' <linda.dunbar@futurewei.com>, 'Keyur Patel' <keyur@arrcus.com>, "Acee Lindem (acee)" <acee@cisco.com>, 'John Scudder' <jgs@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, 'Robert Raszuk' <robert@raszuk.net>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Linda and Keyur:
<chair hat on>
At this point, I will channel John Scudder as well as myself.

At this point, adding these functions to the current draft is out of scope.    The draft has past WG LC and the changes allowed are “errors” or generally accepted “textual changes”.   Keyur and his co-authors last revision was done under those constraints.

Additional features for the tunnel encapsulation drafts will need to go in a follow-on draft.   Many people have proposed follow-on additions.  Drafts related to those follow-on (e.g. draft-hujun-idr-bgp-ipsec-00.txt).

<chair hat off>

Cheerily, Susan Hares

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, July 22, 2019 10:51 AM
To: Keyur Patel; Acee Lindem (acee); John Scudder
Cc: idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org; Robert Raszuk
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Keyur,

Will the Tunnel-Encap draft also add PE WAN ports properties propagation to controlled group of peers (PEs)?
Specifically, the functionality that would help the C-PE to register its WAN Port properties.
In SDWAN scenarios, Some WAN ports are facing public internet with ISP assigned addresses, some WAN ports are assigned with private addresses which need to propagate NAT information to the trusted peers via Controllers, such as the virtual C-PEs instantiated in public Cloud DCs, and some WAN ports are facing the trusted MPLS network.

Linda

From: Idr <idr-bounces@ietf.org> On Behalf Of Keyur Patel
Sent: Monday, July 22, 2019 9:43 AM
To: Acee Lindem (acee) <acee@cisco.com>; John Scudder <jgs@juniper.net>
Cc: idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org; Robert Raszuk <robert@raszuk.net>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Folks,

Draft version 13 is posted. We have redefined “Remote Endpoint Sub-TLV” to “Tunnel egress endpoint”.  We also added text in section 3.1 to clarify the definition of “Tunnel egress endpoint”. Finally, IANA section is updated to request the change the name to “Tunnel egress endpoint”.

Best Regards,
Keyur

https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-13<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-tunnel-encaps-13&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce81eecd6b79a4bd3ec5708d70eb301ae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636994034308649731&sdata=paB0kDdY%2FjWTXRqrONIxn99qxwlXaD3baIiM9xTAzeE%3D&reserved=0>

From: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>
Date: Wednesday, June 12, 2019 at 5:25 PM
To: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>, John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
Cc: "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, "draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>" <draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>>, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <keyur@arrcus.com<mailto:keyur@arrcus.com>>

All,
It occurred to me that “Remote Endpoint Sub-TLV” is somewhat of a misnomer and perhaps there would be less confusion if this were referred to as the “Tunnel Endpoint Sub-TLV”.
Thanks,
Acee

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> on behalf of Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>
Date: Wednesday, June 12, 2019 at 1:57 PM
To: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
Cc: IDR List <idr@ietf.org<mailto:idr@ietf.org>>, "draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>" <draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>>, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Hi John, all

To that point, I am ok with putting in a text that clarifies a  definition of a remote end-point address. What I like to do is provide a flexibility on what that address can be so it can be inserted by controllers (within the same administrative domain).

Please provide a short text describing the endpoint definition and would be happy to incorporate. 😊

Otherwise here is the suggested text for section3.1: “The Remote Endpoint Sub-TLV”:
Instead of:
3.  an address sub-field, whose length depends upon the Address
       Family.
Maybe:
3.  an address sub-field, whose length depends upon the Address
       Family. This is a remote endpoint address for the tunnel. Receiving BGP speaker of this sub-TLV MUST use this address to establish the tunnel.


Regards,
Keyur

From: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
Date: Wednesday, June 12, 2019 at 10:15 AM
To: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>
Cc: Linda Dunbar <ldunbar@futurewei.com<mailto:ldunbar@futurewei.com>>, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>, "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, "draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>" <draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <keyur@arrcus.com<mailto:keyur@arrcus.com>>

(As a contributor)

I guess the disconnect arises from how each reader parses “remote”. To me, and I guess other reviewers who also didn’t notice a problem, it is self-evident that “remote” means “the other end of the tunnel from the point of view of the router encapsulating the packet”. This conversation makes it clear that’s not the only possible reading. As mentioned earlier, I would have no objection to clarifying that point.

—John



On Jun 12, 2019, at 12:58 PM, Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>> wrote:

Hi Linda,

My comments inlined #Keyur

From: Linda Dunbar <ldunbar@futurewei.com<mailto:ldunbar@futurewei.com>>
Date: Wednesday, June 12, 2019 at 8:54 AM
To: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>, "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, "draft-ietf-idr-tunnel-encaps@ietf..org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>" <draft-ietf-idr-tunnel-encaps@ietf..org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>>
Subject: RE: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <keyur@arrcus.com<mailto:keyur@arrcus.com>>

John and authors:

The Section 1.1 says that if R1 sends packets to R2, the remote endpoint of such tunnel is R2. Of course, from R1’s perspective, R2 is the remote endpoint.
But when R2 composes a Tunnel-Encap Update, it is not obvious and not intuitive at all that R2 needs to call itself “remote”. That is where the confusion is. I have raised this question back in -10 version, repeated the question on IDR mailing list, but no one answered.

#Keyur: Hopefully this has been clarified.

Many thanks to John responding to my questions. Those emails have helped me to understand the intent of the draft. But I am sure that many implementors who don’t participate in this discussion and future new people coming to IDR will be confused as I was. No wonder it is so hard for any new people to participate/contribute to IDR.

Simply put, this draft is to announce a node’s tunnel encapsulation capabilities (either by its own, or by a third party), Correct?

#Keyur: And the tunnel endpoint address (minimally. Abstract has it covered).

It will be very helpful to implementors, who are not participating in the discussion today, to add this one sentence to the beginning of Section 3.1:

Remote Endpoint is from receivers’ perspective. When an endpoint A announces its tunnel encapsulation capabilities, it put its own address in the “Remote Endpoint” sub-TLV.

It will be even more helpful to add this sentence to the Abstract and Introduction:
This draft is to announce an endpoint’s (a node or an interface)  tunnel encapsulation capabilities (either by its own, or by a third party), so that receivers can establish appropriate tunnels to this endpoint.

#Keyur: Super. Thanks! As a FYI: There is a text that is in Abstract section 1.2 and section 1.3 which says what you have said and I quote them.

Abstract
<snip>
This document adds support for additional
   tunnel types, and allows a remote tunnel endpoint address to be
   specified for each tunnel.

</snip>

Section 1.2
<snip>
There is no way to use the Tunnel Encapsulation attribute to
      specify the remote endpoint address of a given tunnel; [RFC5512]
      assumes that the remote endpoint of each tunnel is specified as
      the NLRI of an UPDATE of the Encapsulation-SAFI.
</snip>

Section 1.3
<snip>
Defining a new "Remote Endpoint Address sub-TLV" that can be
      included in any of the TLVs contained in the Tunnel Encapsulation
      attribute.  This sub-TLV can be used to specify the remote
      endpoint address of a particular tunnel.

</snip>
Regards,
Keyur


Thank you very much.

Linda








From: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
Sent: Wednesday, June 12, 2019 8:50 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>; Linda Dunbar <ldunbar@futurewei.com<mailto:ldunbar@futurewei.com>>; idr@ietf.org<mailto:idr@ietf.org>; draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

(As an individual contributor)





On Jun 12, 2019, at 6:07 AM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

If A sends an update to B with field of "remote endpoint" does this field apply to A or B ? Is it remote from sender perspective or receiver perspective of BGP update. That is the dilemma here.

If you read section 1.1 you’ll see (emphasis added):


   In this scenario, when R1 transmits packet P, it should transmit it

   to R2 through one of the tunnels specified in U's Tunnel

   Encapsulation attribute.  The IP address of the remote endpoint of

   each such tunnel is R2.  Packet P is known as the tunnel's "payload".

That seems to leave nothing to the imagination. But wait you might say, that describes RFC 5512, how am I supposed to know tunnel-encaps has not reversed the definition? For that, we can take a look at section 5, "Semantics and Usage of the Tunnel Encapsulation attribute”, which is exactly where I as a reader would go look to find the semantics and usage, before I decided to complain they were not clear. The bulleted list in that section leaves no room for doubt as to whether the field applies to A or B: it applies to B.

So, as a reader, who is looking for clarity and not for things to complain about, I think the document is clear.

(As a co-chair)

Despite what the individual contributor said above, if the authors desire to add a short definition of “Remote Endpoint” to address these complaints, I wouldn’t have a problem with that and don’t think it would require another last call period.

Regards,

—John