Re: [Idr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Tue, 04 April 2017 17:08 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 B7837127A97; Tue, 4 Apr 2017 10:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=nistgov.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 8kAp96Vfn6fq; Tue, 4 Apr 2017 10:08:13 -0700 (PDT)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0117.outbound.protection.outlook.com [23.103.201.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A24F127337; Tue, 4 Apr 2017 10:08:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pgF7fxGgihYw0ul/sHtj7R9nKqryrdD/uYeyK5TmSjc=; b=DaAKagzsYSM1/fETqVFOiQn0E38iSPdd0e+wvcadwr2mhm0IjGRelx4dNF6pZgEyb1tfdzZEsBkTDoUIEbuw9B5G35FuQRxPozTwWIpA9Q8tYAO/MpfsBdhBfSlX/Zf1Lwhwm0S+rYy/Owneh6hVEgfjFc87wrc/ovzsT0ax/go=
Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Tue, 4 Apr 2017 17:08:10 +0000
Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.1005.019; Tue, 4 Apr 2017 17:08:10 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Matthew Lepinski <mlepinski@ncf.edu>, "Alvaro Retana (aretana)" <aretana@cisco.com>
CC: "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)
Thread-Index: AQHSrV6hkKLo0jlbPUCXfQgnSjWfzKG1aseAgAABWpA=
Date: Tue, 4 Apr 2017 17:08:10 +0000
Message-ID: <DM2PR09MB0446F7E3A334A58C1C85D461840B0@DM2PR09MB0446.namprd09.prod.outlook.com>
References: <65677770-43DB-4CE0-8E81-B35B9A82DF6F@cisco.com> <CA++NScEB1=TswjnszJm8_kghE2n8MX9gyDPePRsqqNALKyA6=g@mail.gmail.com>
In-Reply-To: <CA++NScEB1=TswjnszJm8_kghE2n8MX9gyDPePRsqqNALKyA6=g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ncf.edu; dkim=none (message not signed) header.d=none;ncf.edu; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [129.6.140.122]
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:YjGr3BHPoS9ss2OcbCUS7BDHRA0ZX6745R9HQQ8Eyfs3t9ZXPQ7f4EvjeXDc9hv7xmEpeUvZ5u0MggtqjZEiSV2S818zO1Vi82CgYRmZfTGjdAfb1WHmgUOmCK9o06Fe1aUWCsoGaA1R3jEbUvNCw9m1/MGkVPxsZoZscfyBX0aqT9jGWSVpvk2ULBy7jQkLcPqU8cblI8lUEqJEWouzSAhLeYuhkp0lPTHlW2KUd9pjXR7iTife2G2ZVcWM8V5ZNpZhL0cxaP1QZAjtmvzC4MIXXroKMSxsG0JWZp5xgX7r2I7m6sVDmJ704Dl4sn9Cy9tuMtltlAxQWl6RtnAT2g==
x-ms-office365-filtering-correlation-id: e00ef82b-251d-4f87-0c37-08d47b7d2bf3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR09MB0448;
x-microsoft-antispam-prvs: <DM2PR09MB0448A16D84D5D615DA01E0FB840B0@DM2PR09MB0448.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448;
x-forefront-prvs: 0267E514F9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39400400002)(39410400002)(39450400003)(39850400002)(24454002)(13464003)(377454003)(25786009)(53546009)(99286003)(55016002)(2906002)(122556002)(5890100001)(230783001)(2171002)(8936002)(189998001)(5660300001)(81166006)(8676002)(9686003)(6306002)(54906002)(2950100002)(6246003)(53936002)(7696004)(54356999)(76176999)(50986999)(3660700001)(33656002)(6436002)(6506006)(77096006)(66066001)(305945005)(102836003)(6116002)(4326008)(2900100001)(86362001)(15650500001)(38730400002)(7736002)(3280700002)(74316002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 17:08:10.2047 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3jHWkBd9dXZuiRoFGVFKjdBKx7g>
Subject: Re: [Idr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 04 Apr 2017 17:08:16 -0000

Hi Matt,

I think slide 4 of this presentation (SIDROPS, IETF 98) addresses your questions/concerns: 
https://www.ietf.org/proceedings/98/slides/slides-98-sidrops-decoupling-bgpsec-documents-and-extended-messages-draft-00.pdf 

Please take a look at slide 3 also (BGP & BGPsec update sizes). 

Also, Alvaro's post from March 15 should be helpful:  
https://www.ietf.org/mail-archive/web/sidr/current/msg08506.html 

Sriram

-----Original Message-----
From: Matthew Lepinski [mailto:mlepinski@ncf.edu] 
Sent: Tuesday, April 04, 2017 12:45 PM
To: Alvaro Retana (aretana) <aretana@cisco.com>
Cc: sidr@ietf.org; sidr-chairs@ietf.org; draft-ietf-sidr-bgpsec-protocol@ietf.org; sidrops@ietf.org; idr@ietf.org
Subject: Re: BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)

Alvaro,

The proposed changes seem reasonable, but I want to make sure that I understand the path forward clearly.

My understanding is that if we were to reach a future where draft-ietf-idr-bgp-extended-messages is widely deployed, then the BGP speaker's maximum message size will just be larger (than it is today) and as a result we avoid reaching the point where Section 9.2 (of
4271) guidance is needed.

Is my understanding correct? (I want to make sure that future implementers will find our text clear and we won't need to revise this spec to add clarity if extended messages ends up in widespread use.)

- Matt Lepinski

On Tue, Apr 4, 2017 at 12:15 PM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
> Dear sidr WG:
>
>
>
> As has been discussed in the mailing list and at the sidrops meeting 
> last week in Chicago, there is interest to not have the BGPsec 
> document
> (draft-ietf-sidr-bgpsec-protocol) depend normatively on the Extended 
> Messages work (draft-ietf-idr-bgp-extended-messages).  Based on that 
> discussion, Sriram and I have come up with proposed diffs – please see 
> the attachment (-23 has not been posted yet).
>
>
>
> To summarize, the changes are: (1) remove mention/references of/to 
> draft-ietf-idr-bgp-extended-messages, and (2) add the following text 
> in Section 4.1. (General Guidance):
>
>
>
>     All BGPsec update messages MUST conform to BGP's maximum message
>
>     size.  If the resulting message exceeds the maximum message size,
>
>     then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be
>
>     followed.
>
>
>
> [For easier reference, I put the relevant text from 9.2 below.]
>
>
>
> The result is then that draft-ietf-sidr-bgpsec-protocol doesn’t depend 
> on draft-ietf-idr-bgp-extended-messages.  Instead, when referring to 
> the size of the messages, it depends on rfc4271.
>
>
>
> Please let me know if you have any concerns.  I will wait a week 
> before proceeding.
>
>
>
> Given that this document has already been approved by the IESG, the 
> process going forward is:
>
>
>
> - consult the WG (this thread)
>
> - inform the IESG of the intent
>
> - inform the IETF (ietf@ietf.org) of the changes
>
> - publish an updated draft
>
> - continue the publication process
>
>
>
> Each step may, obviously, require additional discussion and could 
> result in changes to the current plan.
>
>
>
> Thanks!!
>
>
>
> Alvaro.
>
>
>
>
>
>
>
>
>
> https://tools.ietf.org/html/rfc4271#section-9.2
>
>
>
> 9.2.  Update-Send Process
>
>
>
> …
>
>    If, due to the limits on the maximum size of an UPDATE message (see
>
>    Section 4), a single route doesn't fit into the message, the BGP
>
>    speaker MUST not advertise the route to its peers and MAY choose to
>
>    log an error locally.
>
>