IETF Logo Mail Archive

Re: [sidr] draft-ietf-sidr-bgpsec-protocol

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Tue, 17 January 2017 03:10 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C176129978; Mon, 16 Jan 2017 19:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 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] 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 O36pckbKmtFz; Mon, 16 Jan 2017 19:10:27 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0117.outbound.protection.outlook.com [23.103.200.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 6C6E61294B8; Mon, 16 Jan 2017 19:10:27 -0800 (PST)
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=B1rWIgKOMFAWazWOwUDWedRjOCKpjYbT95mG+xkhNjc=; b=ldwZiax++q3Zs6wKUo5qWQxX3U0FNGmSYsH4hlpXtKBbKU7mQdLFEpIdkqL+/IZ1hj2l+Y6qjCYtJbTmLpEsLF2AREurGmIKFeh1t9ze7lHKAOdrmVw9ihWTgKMco+EGXcTzaC1aC+Om2ZDYQC7nLQY5B9djyZfUbYYNZXa/xSM=
Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Tue, 17 Jan 2017 03:10:25 +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.0845.013; Tue, 17 Jan 2017 03:10:25 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Keyur Patel <keyur@arrcus.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>
Thread-Topic: draft-ietf-sidr-bgpsec-protocol
Thread-Index: AQHSZthkNfH8MXPYLkOmxwl9coeqv6EoZskAgAKH0dSAASfLgIAG7GoAgAjunNs=
Date: Tue, 17 Jan 2017 03:10:25 +0000
Message-ID: <DM2PR09MB04466FE9B0D63383C34F0B5A847C0@DM2PR09MB0446.namprd09.prod.outlook.com>
References: <B3E00907-BF7C-400D-8A5B-4F02BA2A2C12@arrcus.com> <C3B0482B-1007-4B29-B178-DE98C062E197@arrcus.com> <DM2PR09MB0446573C5C4C482D62700B6884630@DM2PR09MB0446.namprd09.prod.outlook.com> <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.com>, <67DBF30E-B262-4568-87FB-96EEF9FB87A9@arrcus.com>
In-Reply-To: <67DBF30E-B262-4568-87FB-96EEF9FB87A9@arrcus.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=kotikalapudi.sriram@nist.gov;
x-originating-ip: [129.6.218.58]
x-ms-office365-filtering-correlation-id: 430755ca-d913-47d3-16bc-08d43e8661ec
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0446;
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:c3uS/jrZH6ElRwzEl44Za08HPTC2JZlVmaU55gl1wGN8e5CLGLlEbWaFwLih1JZ4CkPAWTC8HGbrY3o0UXFBov0B9OUE9RUiyD+kT+AoY5wVWvLIIDwSTVGVMRUmdX6kBNkuwk+GOolrng9q2d9scEkwADWaCWofUz50Jds5u8SCuTGWJSiy/7I3O5BD+sa1Sh5wCbaWnZGXxPNtkeagSUJ6M96+EglIapoc1kTdcXo/lBT5hE2BA5u2QXJhFczg3r1S/05pw0vnIHFF4mWMkwVrBVnGq4P9JR3t2kNy4SknukBUI5JL3NqqiAJFP0SNpE/87xVMNltKTb7IZYJHHYJPO6VkITA7gBAY5bqs2+KLE3UsVjtWZXtJ5iv/e0ATfna22TJ9t7CLrYa+mEpb0yG+5lbCHkfBRmIl/jf+BbkcGfmjkHnpXby8T0hLP3QUAI3CHXztdG3Q0c2S5Vbw2A==
x-microsoft-antispam-prvs: <DM2PR09MB0446E09BB6FF8D1A760DFB5D847C0@DM2PR09MB0446.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446;
x-forefront-prvs: 01901B3451
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(24454002)(52084003)(199003)(189002)(74316002)(55016002)(230783001)(189998001)(77096006)(6506006)(54906002)(99286003)(8676002)(81156014)(25786008)(102836003)(3846002)(4326007)(6436002)(81166006)(93886004)(6116002)(33656002)(30001)(38730400001)(9686003)(8936002)(3280700002)(229853002)(3660700001)(92566002)(122556002)(7696004)(2906002)(105586002)(86362001)(106356001)(2900100001)(68736007)(97736004)(305945005)(5660300001)(106116001)(5001770100001)(54356999)(76176999)(5890100001)(50986999)(66066001)(2950100002)(101416001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 03:10:25.3523 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/-DSw6X21IJniwFpuY6KZ2NrEW0U>
Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, Jonathan Hardwick <jonathan.hardwick@metaswitch.com>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, sidr <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2017 03:10:29 -0000

Hi Alvaro,

... snip ...
Alvaro wrote:
>>I don’t have an objection for this behavior, but I think 
>>we should make the WG (and idr!) aware of the change 
>>and get their comments (if any) before I approve the publication.

Keyur responded:
>#Keyur: Ack. Though I was only requesting some text clarification 
>so that it is very clear to the implementers.

So there was no change required as Keyur points out. 
Oliver also agreed with Keyur's observation when I ran this by him last week.
Per Keyur's request, I have added the following text clarification in Section 7:

   During Graceful Restart (GR), restarting and receiving BGPsec
   speakers MUST follow the procedures specified in [RFC4724] for
   restarting and receiving BGP speakers, respectively.  In particular,
   the behavior of retaining the forwarding state for the routes in the
   Loc-RIB [RFC4271] and marking them as stale as well as not
   differentiating between stale and other information during forwarding
   will be the same as specified in [RFC4724].

...snip...
Alvaro wrote:
>>…how should an iBGP speaker perform loop detection 
>>if there’s no BGPsec_Path attribute?  In other words, 
>>there is no defined mechanism to run the algorithm in 4.4 without it.
>>
>>I’m not suggesting that you include an empty attribute, 
>>but that you indicate in 4.4 that no BGPsec_Path attribute 
>>is equivalent to an empty AS_PATH.

Per your suggestion, I have added the following text in Section 4.4: 

   Finally, one special case of reconstruction of AS_PATH is when the
   BGPsec_Path attribute is absent.  As explained in Section 4.1, when a
   BGPsec speaker originates a prefix and sends it to a BGPsec-capable
   iBGP peer, the BGPsec_Path is not attached.  So when received from a
   BGPsec-capable iBGP peer, no BGPsec_Path attribute in a BGPsec update
   is equivalent to an empty AS_PATH [RFC4271].

Please let me know if you have any comments/questions. 

Thank you.

Sriram

v2.23.0 | Report a Bug | By Email