Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Keyur Patel <keyur@arrcus.com> Fri, 18 October 2019 16:03 UTC

Return-Path: <keyur@arrcus.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 460A01208D9; Fri, 18 Oct 2019 09:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=netorgft1331857.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 Yd_UV1dR608r; Fri, 18 Oct 2019 09:03:46 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780072.outbound.protection.outlook.com [40.107.78.72]) (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 B7FF21208CF; Fri, 18 Oct 2019 09:03:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i+pRiiJCfahgvrw0ELdH5pjskpZdpb7AK/EzGU0qSaoCYyFK0psXZ7j4qT3Wd62Let1Y7kilFuG0x9SMeAs5A9aVgK0uHlEWCcne93W7Lz+cGyFSjnJiNiR/28alyfCzFVU8RDK2FN6mgFuZQFFD3zioxbtYkbyVY7umZCqkEuLVYUwFGfqbRUozp8xFucXBztv+fxPwyDBDqiXnFHiU2aUe4s6qR277LHK7lbdgMqjB3NkRy0uzuCrA4KB81NlrgmRwsKFBwmqnnIWd58SDEBn896cPK4ny3F8yloDPP2VjSK0saLw9+bjr+ejF3anrw6NZjv7u6zTOr0PmOgfIOg==
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=PdkuK0BNYlYRyzXaMNyiNdJy/RA3vjvluKnqPeHENaE=; b=cQH04MeaB3HrF98m2Wdc06wTpjfavOOlIV0qmwXo/l8TRGy0nMGZt5lm5Ac5FLZvpOYknXSdasbJcs3B8oVChlbGGpMtrKICnt0UfgDi6OkjWCwGYr37X9AbSXUV+zuirxIoATdb6Xpz4IXk8O8EMkFDxpP6zQmhjcDWGa2v2yQb9ddvh+PstXYEeTjgPc6VQEGKKYUGYkPEdUELdmj4nCffc0vPCQgHEBphpG7zueyWsbBuhjrFcDh2ANqi4j0sdIaVu4vHBI9Hvd3X641elI6oaORdlJx2ETuy5r1/pLuO1SZrcvCkzs1FS41szOj5amsF9/zD1zHIIcChhS5jlg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PdkuK0BNYlYRyzXaMNyiNdJy/RA3vjvluKnqPeHENaE=; b=VyxGH2eky8itvcKYNHa+kA+PdllOQK+0Mi+dqEO53pvbpKS6AH58Puf4S7WV3Fuwm9c6gKQD6hHFS9KaX7LedLVSmPUm6BLoDipPfOd2cjIgj/8f1W+iAlI6ORgsmfo1jqFEHdwqJbFd6iT2hF2q5SZMNEMF8QKDgg7PkX7XBVY=
Received: from BYAPR18MB2856.namprd18.prod.outlook.com (20.179.59.30) by BYAPR18MB2933.namprd18.prod.outlook.com (20.179.59.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Fri, 18 Oct 2019 16:03:43 +0000
Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::6182:28f2:3566:d173]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::6182:28f2:3566:d173%3]) with mapi id 15.20.2347.024; Fri, 18 Oct 2019 16:03:43 +0000
From: Keyur Patel <keyur@arrcus.com>
To: Robert Raszuk <robert@raszuk.net>
CC: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, Ondrej Zajicek <santiago@crfreenet.org>, "idr@ietf.org" <idr@ietf.org>, Linda Dunbar <linda.dunbar@futurewei.com>, Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Thread-Topic: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
Thread-Index: AQHVhL8lFDuHxnzddkaD1lVXXD4SAKdeeoqAgAAEwoCAABL6AIAAECQAgADTL4CAAARggP//oSsAgAEAXICAAAC6gA==
Date: Fri, 18 Oct 2019 16:03:42 +0000
Message-ID: <7A57D31B-F4D9-42B1-9119-34C3EBBA46DE@arrcus.com>
References: <MN2PR13MB3582A1E1FE3441CDD54A101985950@MN2PR13MB3582.namprd13.prod.outlook.com> <78F7A474-6F86-4EA3-93A3-001B4E2C2116@juniper.net> <CAOj+MMGqKj=zKbws92ni1fL2O-So=dbcW-mb02uRnQ+G55xm_w@mail.gmail.com> <0B48E5E7-3A1F-45C0-ACF9-B9A0FA323ED4@juniper.net> <CAOj+MMHs91BoMpgrN2-qtMAgVtiUE_e2bm=BG=+xVnfU9-6Aaw@mail.gmail.com> <20191017093308.GB2427@feanor.crfreenet.org> <CAOj+MMFs=StpLvK1dZO+ChBUN5i2AYq+CrhHMfMxifpxqegwiw@mail.gmail.com> <2A6A8F0A-82B2-4016-9148-10B4FC75FC03@cisco.com> <CAOj+MMECVbe-VOP2D5mB+zZWjLh_igOefeFYbK-OMtJ+bY9EGA@mail.gmail.com> <A55F4BE5-9AD7-4776-9FE1-8A9A47E4F468@arrcus.com> <CAOj+MMF3FhCDjXQYtaS1PNZ6z79o41dcxkLE2Fbyaq8+yCCS_Q@mail.gmail.com>
In-Reply-To: <CAOj+MMF3FhCDjXQYtaS1PNZ6z79o41dcxkLE2Fbyaq8+yCCS_Q@mail.gmail.com>
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=keyur@arrcus.com;
x-originating-ip: [70.234.233.187]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 67809de3-b2c9-46ab-b4a0-08d753e4bfda
x-ms-traffictypediagnostic: BYAPR18MB2933:
x-microsoft-antispam-prvs: <BYAPR18MB2933EF76A0B1378D10D5527AC16C0@BYAPR18MB2933.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4941;
x-forefront-prvs: 01949FE337
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(376002)(396003)(39830400003)(199004)(189003)(186003)(14454004)(66066001)(8936002)(6512007)(2616005)(6116002)(3846002)(26005)(76176011)(7736002)(6506007)(53546011)(102836004)(33656002)(5660300002)(71190400001)(71200400001)(6916009)(54906003)(8676002)(66476007)(66946007)(64756008)(66446008)(508600001)(76116006)(6306002)(316002)(81156014)(81166006)(486006)(446003)(36756003)(54896002)(99286004)(14444005)(256004)(229853002)(6436002)(2906002)(5024004)(25786009)(476003)(86362001)(11346002)(66556008)(6246003)(4326008)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2933; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hgNIY9clrsfTjrM13dhITp9NilD6VNBBRqSvdr7zPiFOr8OadgpYL9Gx0MhSzPb5V6OSZTaXh2i32gL09cLPrPFgM+5Qo/YFwKLzic56kMvZSo9cCjKyiyBnjluJzQNIs4uC6QmyTFtVCCf0ntuDC8Blcwd8TGZOlAiGe2V1vpeqVnF6cRfHYPysLZaGFNAj6d3ncnQSt7eo5uuPYp8BT+/Rqo6ffpdGVHbg8z5TokYf1m5r6i7xcAETFX9YPFj3KHyX/HibQXfcmM13LmayGM6EJZKER8IWyXRp0dMUcOG+jAWcDFiqsFYpKzGdDwZHn5p6MKs90SS7a9/vL8HOtwXc1gGflIVYkZeggUTyyEp6efXvg1x8LYYZ5x4d0HpwcMTKvdX3Ph9hALagPtnGZcvJCm2HSTilA2IGM4gyY8I=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_7A57D31BF4D942B1911934C3EBBA46DEarrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67809de3-b2c9-46ab-b4a0-08d753e4bfda
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 16:03:43.0116 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wDsqvUbHrch5FxySVI4+QR6TG52LAqYILRwqf7nUCYJzJAD2yhj8tzZ7T6ex6nsAGsIBLacYs+lsEo+8rMwL3Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2933
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6AWKC5H7OXW2t2eUHfOJEavNhYE>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
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: Fri, 18 Oct 2019 16:03:50 -0000

Robert,

Comments inlined #Keyur1

From: Robert Raszuk <robert@raszuk.net>
Date: Friday, October 18, 2019 at 2:00 AM
To: Keyur Patel <keyur@arrcus.com>
Cc: "Rajiv Asati (rajiva)" <rajiva@cisco.com>om>, Ondrej Zajicek <santiago@crfreenet.org>rg>, "idr@ietf.org" <idr@ietf.org>rg>, Linda Dunbar <linda.dunbar@futurewei.com>om>, Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>rg>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Hey Keyur,

Why don't we use basic BGP recursion (in any AFI/SAFI required) and simply advertise within each applicable SAFI an NLRI = NH of endpoint/customer routes with NH = Tunnel Endpoint while attaching to such UPDATE  Encapsulation Extended Community indicating type of tunnels and parameters required ?

#Keyur: You can still announce the tunnel endpoint (underlay) route using tunnel endpoint attribute. The attribute gives you a common placeholder to carry tunnel parameters (including endpoint) and specifically as and when parameters grow beyond size of community/ext community/large community.

Size is a fair point .. while type of the encap will easily fit in communities some other associated info may not.

But in the case I described there is no need to put tunnel endpoint address in the tunnel attribute. How about you update the draft and make tunnel endpoint address TLV optional - and if not present next hop is used as tunnel endpoint ?

#Keyur1:  This has been debated before afair. You don’t want different encapsulations to be handled in different ways. There is benefit in having them within a common placeholder (which is actually cheap and further solves any interdependencies if mandated).


Of course most if not all of other observations still apply :)  And the point here is that to get consistent implementations draft should add perhaps even a new paragraph on how to handle difference in next hop validation vs tunnel endpoint validation.

#Keyur1: Please note that the implementations are already there in various forms.

Is in the case of presence of reachable (or poor man's check existing in the RIB) tunnel endpoint address BGP next hop validation and tracking still making sense ?

#Keyur1: Agree. Then again section 5 does refer to reachability aspects of the tunnel endpoint. IMHO, the specifics of tracking of tunnel ip address is an implementation detail.

Then how to address similar "collisions" with Origin Validation results ?

#Keyur1: Collisions of origin validation result is usually a matter of network specific policies mandated by operators (They may permit or may deny making a specific tunnel ineligible).

Regards,
Keyur


Thx,
r.