IETF Logo Mail Archive

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

"Alvaro Retana (aretana)" <aretana@cisco.com> Fri, 03 February 2017 20:17 UTC

Return-Path: <aretana@cisco.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 6D39F1298B2 for <idr@ietfa.amsl.com>; Fri, 3 Feb 2017 12:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.719
X-Spam-Level:
X-Spam-Status: No, score=-17.719 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, URIBL_BLOCKED=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 syHeUeZr2X-5 for <idr@ietfa.amsl.com>; Fri, 3 Feb 2017 12:17:41 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BC1129456 for <idr@ietf.org>; Fri, 3 Feb 2017 12:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18870; q=dns/txt; s=iport; t=1486153061; x=1487362661; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6PkJh6eisDInNp0pOAChyVt/lNPpSWqHKXFjlux8B5Q=; b=ZNdL+Fsd3Nuc8XlOiAHJk/8sYMvCpcgWn3SvuS8Izk7pD6CepaQQbxmi W1u6U7fKEoJ9dTUJhPBso7JnwFo8Y1DhghXzyaN4c94h/UuELGtONgQBU n32KO0dDeIRPwBFLwNZrhjZK5hV09rBR/CcRvydMHD/JQpuddxIfvqoZt I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BpAQA05JRY/5NdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgm9kYYEJB4MLRooIkW2QL4Urgg0uhXQCGoJFPxgBAgEBAQEBAQFiHQuEagYMF1YQAgEGAj8DAgICMBQRAgQOBRSJXQ6QfJ1OgiUrixABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZLggUIgmKDEIRDLoIxBZVKhhkBkgeBe4UXiXCIKIphAR84gUsVTAGELYIDdYgVgQwBAQE
X-IronPort-AV: E=Sophos;i="5.33,330,1477958400"; d="scan'208,217";a="381093730"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2017 20:16:39 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v13KGdph014043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2017 20:16:39 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.1210.3; Fri, 3 Feb 2017 14:16:39 -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; Fri, 3 Feb 2017 14:16:39 -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+CAALACAIAAziXggrqjygA=
Date: Fri, 03 Feb 2017 20:16:38 +0000
Message-ID: <CFE79035-2FFA-4B7A-9574-80D46137E3DF@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> <D26F8B7E.EA6BA%aretana@cisco.com> <9781_1447749309_564AE6BD_9781_1504_1_53C29892C857584299CBF5D05346208A0F6BD227@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <9781_1447749309_564AE6BD_9781_1504_1_53C29892C857584299CBF5D05346208A0F6BD227@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.3]
Content-Type: multipart/alternative; boundary="_000_CFE790352FFA4B7A957480D46137E3DFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4tYjDIre-Eo7LQ3srnxYImvhbtI>
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.17
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, 03 Feb 2017 20:17:43 -0000

Bruno:

Hi!

We just refreshed the draft…and (I think) clarified your point below in the Security Considerations:

Section 6., paragraph 2:
OLD:

    To minimize the potential of creating routing loops (Section 5) or
    otherwise affecting the Decision Process in unintended ways, the
    propagation of Cost Communities MUST be disabled by default and MUST
    be explicitly enabled by the network administrator.  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.

NEW:

    To minimize the potential of creating routing loops (Section 5) or
    otherwise affecting the Decision Process in unintended ways, the
    propagation of Cost Communities MUST be disabled by default and MUST
    be explicitly enabled by the network administrator.  Furthermore, all
    Cost Communities received across an Autonomous System boundary
    without explicitly being enabled MUST be stripped off the BGP update,
    and ignored during the Decision Process.


That is probably the main part, but there are other changes resulting from your comments.  Please take a look at the complete diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-custom-decision-07&url2=draft-ietf-idr-custom-decision-08


Thanks!

Alvaro.

On 11/17/15, 3:35 AM, "bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>" <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

My concern is for an AS not using this cost community:
a) compliant routers will, by default, modify route preference based on the community
b) non compliant routers will, by default, accept this community over eBGP sessions.

a+b: we have an issue as untrusted AS may influence my routing policy or create loops.

We agree that we can’t do anything about “b”.
So I am asking to address “a” by having compliant routers to _not_ change route preference by default. i.e. MUST be explicitly configured to change their route preference based on this community.

v2.23.0 | Report a Bug | By Email