IETF Logo Mail Archive

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

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 17 January 2017 15:49 UTC

Return-Path: <aretana@cisco.com>
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 5706D129512; Tue, 17 Jan 2017 07:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level:
X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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
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 dgraEaPGECUs; Tue, 17 Jan 2017 07:49:28 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC6B129532; Tue, 17 Jan 2017 07:49:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16008; q=dns/txt; s=iport; t=1484668166; x=1485877766; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bIWw18fZdD77vEhDOGOvztWRWQc1bN1WCu/2DlmceyE=; b=DQoan/3d8ESIxgdKdX3/AtB6I6dTcJtvU7tJX8H5U/4Drt0pom7BVox8 EbSLug7vNf9M74KeYE2ES6R1KtybVfv9KBqXOddMKQKXHE/3YiiCsUsJb 61MW1x1Xe5i2O1P9XRPEBKL8EO5rAAtspzouHweoo47R4bItkjQ31iwva Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AeAQAePH5Y/5NdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgm9KAQEBAQEfX4EJB4NKigeiGYUrgguGIgIagXg/GAECAQEBAQEBAWMohGoGI1YQAgEIPwMCAgIwFBECBAENBYkDr0KCJSuJWQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYICgmWHTi2CMQWVL4YLAZFegXeFDoNNhhuIGopRAR84gUQVSgGGIXOHS4ENAQEB
X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208,217";a="372979882"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 15:49:25 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0HFnOY9015215 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jan 2017 15:49:24 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 09:49:23 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 09:49:23 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Keyur Patel <keyur@arrcus.com>
Thread-Topic: draft-ietf-sidr-bgpsec-protocol
Thread-Index: AQHSaHILNfH8MXPYLkOmxwl9coeqv6EoZskAgAKH0dSAASfLgIAG7GoAgAjunNuAAQEAgA==
Date: Tue, 17 Jan 2017 15:49:23 +0000
Message-ID: <0E5D570D-46F3-476B-A890-920172BAF10A@cisco.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> <DM2PR09MB04466FE9B0D63383C34F0B5A847C0@DM2PR09MB0446.namprd09.prod.outlook.com>
In-Reply-To: <DM2PR09MB04466FE9B0D63383C34F0B5A847C0@DM2PR09MB0446.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.3]
Content-Type: multipart/alternative; boundary="_000_0E5D570D46F3476BA890920172BAF10Aciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/Phr0GAd61p8maDw9yP6rU9LthyE>
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 15:49:30 -0000

Sriram:

Hi!

Yes, I think I may have read more into Keyur’s comment than what he was asking for, so I think we’re ready to go. ☺

I’ll approve publication.

Thanks!!

Alvaro.

On 1/16/17, 10:10 PM, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov<mailto:kotikalapudi.sriram@nist.gov>> wrote:

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