Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

"Alvaro Retana (aretana)" <aretana@cisco.com> Mon, 16 November 2015 19:03 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB3F1A8797 for <idr@ietfa.amsl.com>; Mon, 16 Nov 2015 11:03:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.085
X-Spam-Level:
X-Spam-Status: No, score=-15.085 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 WG6LiZ4eP22E for <idr@ietfa.amsl.com>; Mon, 16 Nov 2015 11:03:27 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC49B1A878C for <idr@ietf.org>; Mon, 16 Nov 2015 11:03:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55090; q=dns/txt; s=iport; t=1447700607; x=1448910207; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0aYAXiaakpivpb4Nc14v/7o1rmNxD5NMFZapFo2yq+4=; b=ctxizf2XUtDymB2awApwT8e4Qu2CMpDENf0Y6bxxq9n8CcroSR82n7z4 6rG/KY6aRsXDQM3hV694PKO7iIw5wg0YJoVQshnCYXTZCGcHl4i6RTZzx jhLLdy2cNfwxnrYHW9LR9KkKzm35YWMMJCBIn/bVkpki4+3kdRYMIWtxf k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgA5KEpW/4cNJK1dgm5NU28GtiOFK?= =?us-ascii?q?4MMAQ2BZIYQAoFHOBQBAQEBAQEBgQqENQEBAwEtTAULAgEILQsBBgcmDBQRAgQ?= =?us-ascii?q?OBAEUiBIIuxsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlQBhH2EKXGEHwWNVIUTg?= =?us-ascii?q?2EBiA2FGYFbkhaEYoNxAR8BAUKEBHKERIEHAQEB?=
X-IronPort-AV: E=Sophos; i="5.20,303,1444694400"; d="scan'208,217"; a="50192905"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2015 19:03:05 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAGJ34L2001306 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2015 19:03:04 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 Nov 2015 13:03:04 -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.1104.000; Mon, 16 Nov 2015 13:03:03 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Thread-Topic: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)
Thread-Index: AQHQfOJEbzqBqbwli0WLinaFdrSzRp5/NkAAgCBzp+CAALACAA==
Date: Mon, 16 Nov 2015 19:03:03 +0000
Message-ID: <D26F8B7E.EA6BA%aretana@cisco.com>
References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <D24E929A.E0D85%aretana@cisco.com> <30646_1447691076_564A0344_30646_2291_1_53C29892C857584299CBF5D05346208A0F6BC240@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <30646_1447691076_564A0344_30646_2291_1_53C29892C857584299CBF5D05346208A0F6BC240@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.238.17]
Content-Type: multipart/alternative; boundary="_000_D26F8B7EEA6BAaretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/9RhKHgPWa5T8HIsOZ5yzok4crtg>
Cc: "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 16 Nov 2015 19:03:31 -0000

On 11/16/15, 11:24 AM, "bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>" <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

Bruno:

Hi!

Looks good to me, except one point regarding the security consideration. Then I also have some further comments.

--
>>§6.  Security Considerations

[...]
>> a) by default, this mechanism is activated.
>> b) non compliant implementation will accept and pass transitive Opaque community (0x03)

>> a+ b): anyone in the Internet can influence the routing in my AS; which is not acceptable.

> Yes, you're right.  We added considerations to turn it off by default.

I've only seen "MUST not propagate by default" which is not something this document can enforce on non-compliant ASBR. Hence some non compliant ASBR will accept this Cost  Community from unstrusted source/AS and propagate it within the AS.
IMO, we need that by defaut, the cost community MUST NOT affect the BGP decision process.

I think that this case is addressed in the text below (mod transitive + non-transitive).

You're right that a non-compliant implementation can do what is not specified (accept, propagate, use).  The same obviously applies to any other normative language we can add..




"Furthermore, all

   transitive Cost Communities received across an Autonomous System

   boundary without explicit configuration MUST be stripped off the BGP

   update, and ignored during the Decision Process."


Transitive and non-transitive (MUST be stripped off) (As RFC 4360 does not specify to remove non-transitive community received over eBGP.)

The last sentence in Section 4 (Operation) reads:

   If the non-transitive version of a Cost Community is received across
   an Autonomous System boundary, then the receiver MUST strip it off
   the BGP update, and ignore it during the Decision Process.

I think we were thinking about the inter-AS case when we wrote the Security Considerations..so we left the non-transitive part out.  We can add it in the next revision to make sure it is clear.


---

OLD: If the high-order bit is set, the Cost in the Cost Community
         may replace the value of a path attribute at a specific step in
         the Decision Process, but not the attribute itself.
NEW: If the high-order bit is set, the Cost in the Cost Community
         replace the value of a path attribute at a specific step in
         the Decision Process, but not the attribute itself.

Will fix in the next revision.



---

"   Multiple Cost Communities may indicate the same POI.  All the Cost

   Communities for a specific POI MUST be considered starting with the

   one(s) with the lowest Community-ID. "

By "lowest Community-ID" it's not clear to me whether the high order bit (indicating _after_ or _instead_ the related BGP attribute) is taken into account or not (i.e. should be masked before the comparison).
IMHO I would favor not taking this bit into account as, a priori, I don't see a reason to give preference to POI _after_.  In which case, as a related comment, IMHO the first figure of section 3, should indicate this high order bit as a separate field.
Regardless of your choice, IMO the expected behavior should be explicitly stated.

We'll change the drawing to indicate the bit separately and clarify what the ID is - in the next revision.


 "All the Cost Communities for a specific POI MUST be considered"

I'm not sure I would consider comparable "POI X & High-Order bit 1" with "POI X & High-Order bit 0". To me, looks like nearly equally different than POI X and POI X+1.

Oh, that doesn't mean that they are compared against each other.  As you point out, the "effective POI" with the high-order bit set is different than without it.

Along with your other comment about the ID and the high-order bit, we'll also clarify the meaning of POI.

By separating the high-order bit into its own field the meaning of the ID is cleared.  We'll call it the "Replace Bit" (R-bit).   I'm thinking of adding a new term called the Point of Application (POA), which is the place in the Decision Process where the Cost Community is evaluated.  If the R-bit is not set, then the POA is after the step in the Decision Process indicated by the POI; if the R-bit is set, then the POA is at the POI.  I'll then s/POI/POA in Operation, etc. which should result in the clarified behavior.   Thoughts?

 --

"   Routes that do not contain the Cost Community (for a valid,

   particular POI),or a Community-ID present in a route from another

   peer, MUST be considered to have the default Cost"

"(for a valid, particular POI" + and high-order bit of the community-ID.

Yes..  As above.

Thanks!

Alvaro.