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

Linda Dunbar <ldunbar@futurewei.com> Wed, 12 June 2019 15:54 UTC

Return-Path: <ldunbar@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 1907E120192; Wed, 12 Jun 2019 08:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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=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 lBXv-z-CAIl4; Wed, 12 Jun 2019 08:54:49 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690132.outbound.protection.outlook.com [40.107.69.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1273A120203; Wed, 12 Jun 2019 08:54:19 -0700 (PDT)
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=FyO8qBk4HMdTPf9DAqUw1t1L1BzMxMrAF/dCGzk6N9E=; b=h7a/bkPl/1TFydM2+B/PHgb7KDH6iUGiuAE5vnyWHYPjpdJYRQDE8jD7nk4qzD5xmn8eZnWAAwvfiVHlmBpDjly2DtbD6/kuFDaNTYcAKtJHeTiiWMQ+CbVzzQX7KPH/fUtoXoorMX5VXzqyNIHP9ItRtNwyR5FuAO5u6hwbMY8=
Received: from MN2PR13MB3582.namprd13.prod.outlook.com (10.255.238.139) by MN2PR13MB3390.namprd13.prod.outlook.com (10.255.236.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.5; Wed, 12 Jun 2019 15:54:18 +0000
Received: from MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::b5e8:95cb:5d8e:9397]) by MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::b5e8:95cb:5d8e:9397%7]) with mapi id 15.20.1987.010; Wed, 12 Jun 2019 15:54:18 +0000
From: Linda Dunbar <ldunbar@futurewei.com>
To: John Scudder <jgs@juniper.net>, Robert Raszuk <robert@raszuk.net>
CC: Keyur Patel <keyur@arrcus.com>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Thread-Topic: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Thread-Index: AdUfzDTwk+JWx4NrTbCw24feqIEcxQADfhQAAABU8AAALY6XEAAB/DuAAADA04AAGnlYgAAHy0SAAANKonA=
Date: Wed, 12 Jun 2019 15:54:18 +0000
Message-ID: <MN2PR13MB3582C58B3C84105B43191547A9EC0@MN2PR13MB3582.namprd13.prod.outlook.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>
In-Reply-To: <68538D45-E8CD-4FDA-ABA4-BEC4A7586410@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ldunbar@futurewei.com;
x-originating-ip: [12.111.81.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 509cf2f5-bfaf-4874-3662-08d6ef4e3a34
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR13MB3390;
x-ms-traffictypediagnostic: MN2PR13MB3390:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR13MB339055FB2BD3CE7D5114F503A9EC0@MN2PR13MB3390.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0066D63CE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(396003)(39850400004)(376002)(199004)(189003)(76176011)(53546011)(26005)(316002)(25786009)(102836004)(6506007)(229853002)(6436002)(11346002)(76116006)(446003)(186003)(236005)(66946007)(73956011)(55016002)(66476007)(66556008)(476003)(64756008)(486006)(9686003)(6306002)(54896002)(53936002)(68736007)(66446008)(7736002)(8936002)(54906003)(110136005)(81166006)(5660300002)(33656002)(81156014)(6246003)(52536014)(8676002)(99286004)(14444005)(256004)(2906002)(74316002)(4326008)(1941001)(66066001)(508600001)(86362001)(71190400001)(71200400001)(7696005)(14454004)(790700001)(3846002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB3390; H:MN2PR13MB3582.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sFLIZYi3kq+UO7wTrtOqsNbgji1M+MCE7/TYSwXqKpybK/RRzfQSVfTjBV5en80MJSDNs3YtH1p3KzuqAd/nFamzNTnzsstBDnUFRnxUn4CePuZiweuuePWfBXALN2bAPd9PBThFob/1JulhFN1hUZZlzyupQ8SVyHP1GPqxMqKRtWu5RiCLhlqs5FUo0xYKfTfK2vhzM4ZWGvQyE0b8nPUqk/R27RyvQyBx3PRcr4FSQJWj5eALvc5sY3ocRdtyRzs7dOwKFtIqIha53pekf6RowObpffMz9ENaRpGgmlfEGgUwGHnuLK/vND2qzTDgxAzqzTJVTEVf2wHzCbbcNwKn7ELeevOXcTpNsmI/ze2G6l7iiVc/iAx8q+Z1rkwURNWm8DfQniG6IP/wqakVa6G0kn7fjnKbt6TnJqjDnyM=
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3582C58B3C84105B43191547A9EC0MN2PR13MB3582namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 509cf2f5-bfaf-4874-3662-08d6ef4e3a34
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 15:54:18.1142 (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: ldunbar@futurewei.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3390
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/E_hWg87taMY1g7oRCYv4kPjwqgo>
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: Wed, 12 Jun 2019 15:54:53 -0000

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.

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?

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.

Thank you very much.

Linda








From: John Scudder <jgs@juniper.net>
Sent: Wednesday, June 12, 2019 8:50 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: Keyur Patel <keyur@arrcus.com>om>; Linda Dunbar <ldunbar@futurewei.com>om>; idr@ietf.org; 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