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

"Alvaro Retana (aretana)" <aretana@cisco.com> Mon, 26 October 2015 16:59 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 3D3C51B43FF for <idr@ietfa.amsl.com>; Mon, 26 Oct 2015 09:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.242
X-Spam-Level:
X-Spam-Status: No, score=-4.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] 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 iP4HTdXmiHFn for <idr@ietfa.amsl.com>; Mon, 26 Oct 2015 09:59:34 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF151B4F23 for <idr@ietf.org>; Mon, 26 Oct 2015 09:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=308839; q=dns/txt; s=iport; t=1445878773; x=1447088373; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mvPglxxkpnfyo/6x/maTBV+CLeds0qO+7+1B9rvNlzg=; b=PIiSV1AuKGCqwgDh+b7oNVItdPmMejyFeq2MI2KJYix7dwZIUaZ79pqP bosgSqxkFEoPud9JiEBbUuQ/ZITxHnyCthOUvnf3JT/Imv7qwn/ce357j BBJZWriW+Aw76ZaYt8VS9cjQZt/idILwgZeV+1q5Kg/mFX/8nG63tk5Vp 0=;
X-Files: draft-ietf-idr-custom-decision-07.txt, Diff_Cost_Community_06_to-07.htm : 22778, 183846
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfBACwWi5W/4wNJK3OIgICAQI
X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="htm'217?txt'217?scan'217,208,217";a="44614281"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP; 26 Oct 2015 16:59:32 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9QGxWV9002711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 16:59:32 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 11:59:08 -0500
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, 26 Oct 2015 11:59:08 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Eric C Rosen <erosen@juniper.net>
Thread-Topic: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)
Thread-Index: AQHQgevLgsE2vXkKvUi3Bb2JhSp62J5/LEAA
Date: Mon, 26 Oct 2015 16:59:08 +0000
Message-ID: <D24E9494.E0D99%aretana@cisco.com>
References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> <553FE30E.4080902@juniper.net>
In-Reply-To: <553FE30E.4080902@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.3]
Content-Type: multipart/mixed; boundary="_003_D24E9494E0D99aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/F9Hp1Q3qFyfyDBkGRSijxSMSKFk>
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, 26 Oct 2015 16:59:46 -0000

On 4/28/15, 3:44 PM, "Idr on behalf of Eric C Rosen" <idr-bounces@ietf.org
on behalf of erosen@juniper.net> wrote:

Eric:

Hi!  Sorry for the long delay..

Since we missed the ID deadline (several of them), I'm attaching what will
be version ­07 and the diffs..along with specific answers to your comments
below.

Thanks!!

Alvaro.




>I think there are a few issues that should be addressed before
>publication of this draft is requested.
>
>1. IANA Considerations and Extended Community Sub-Type Registries
>
>The document should be brought into conformance with RFC 7153 ("IANA
>Registries for BGP Extended Communities").
>
>Specifically, I think section 3 should begin something like:
>
>"IANA has assigned the codepoint value 1 to 'Cost Community' in both the
>Transitive Opaque Extended Community Sub-Types registry and the
>Non-Transitive Opaque Extended Community Sub-Types registry."  When a
>Cost Community is attached to a BGP Update, it is determined by
>provisioning whether the transitive or the non-transitve Cost Community
>is used.
>
>Then just go on to define the Value field.
>
>Similarly, the first paragraph of the IANA Considerations section should
>be:
>
>IANA has assigned the codepoint value 1 to 'Cost Community' in both the
>Transitive Opaque Extended Community Sub-Types registry and the
>Non-Transitive Opaque Extended Community Sub-Types registry."

Both sections were updated.


>2. Mandatory features?
>
>The draft doesn't say anything about which PoIs, if any, are mandatory
>to implement if Cost Community is supported.  Is it the intention that
>none of the PoIs be mandatory?
>
>Whether a given PoI is mandatory or not, is it required that a given PoI
>not be used in a given AS unless all BGP speakers in that AS support it?
>  If not, how is consistency of routing ensured?

We added some text in both the Deployment and Security Consideration
sections.  The bottom line is that the need to support a specific POI
depends on the policy in a specific AS.  This leads to making the operator
responsible for the proper design (where all the impacted routers in the
network support the needed POIs) and deployment of the policies.

While the Cost Community is a general mechanism, our deployment experience
tells us that the most used POIs are ABSOLUTE_VALUE and IGP_COST.


>3. Community-ID high order bit
>
>       "The Community-ID sub-field contains an identifier to distinguish
>       between multiple instances of the Cost Community.  The high-order
>       bit is reserved to indicate that the Cost Community MUST replace
>       the path attribute specified by the Point of Insertion during the
>       best path selection process."
>
>Before this paragraph, the draft talks about considering the Cost
>Community AFTER considering the attribute identified by the PoI.  This
>paragraph suggests that if the high-order bit of the Community-ID is
>set, the Cost Community is considered INSTEAD of the attribute
>identified by the PoI.  It might be better if the previous text in the
>draft talked about considering the Cost Community "after or instead of
>..., depending on the setting of the high-order bit of the Community-ID."

We added that to the POI field description:

      The Point of Insertion (POI) sub-field indicates *after*, or
      *instead of*, which step in the Decision Process the Cost
      Community MUST be considered.




>However, I don't understand what to do if you are comparing two routes,
>and for a given PoI and Community-ID, one of them has the high order bit
>set in the Community-ID and one does not.

Note that setting the high-order bit makes the POI slightly different: it
is now replacing the step in the selection process.

If we then receive a route with the high-bit set and another w/out it, we
wouldn't compare them directly.  We would first consider the one w/the
high-bit set *instead* of the attribute it replaces..and then consider the
one w/out the high-bit set.


>Similarly, if one route has a particular Community-ID for a given PoI,
>and another does not have that Community-ID for that PoI, how do we
>react to the setting of the high-order bit when we compare the two routes?

If the route that has a Community-ID for a POI also has the high-order bit
set, then that Cost Community would be considered instead of the attribute
it replaces.  The other route, which doesn't have a Cost Community for
that POI would still have the "normal" attribute to compare.


>4. Questions about particular PoIs
>
>a. ABSOLUTE_VALUE.  Is the intention here that ABSOLUTE_VALUE be used to
>assign the "degree of preference" (RFC4271 section 9.1.1) to a route,
>and that LOCAL_PREF, if present, be used as a tie-breaker when all the
>feasible routes have the same ABSOLUTE_VALUE?  If so, it would be good
>to say that explicitly.  Other text in the draft suggests that Cost
>Community is only used for "breaking a tie among generally equal paths",
>while text in RFC4271 suggests that LOCAL_PREF is used to assign degree
>of preference and not to break ties.

We clarified the definition.

>
>Is there any signficance to the high-order bit of the Community-ID if
>the PoI is ABSOLUTE_VALUE?

No.  We added text to say that it "MUST be ignored when used with the
ABSOLUTE_VALUE POI".


>b. EXTERNAL_INTERNAL.  I think this needs a better explanation of just
>when in the decision process it is considered.  Does this refer to
>paragraph d of section 9.1.2.2 of RFC 4271?

Yes.

>c. IGP_COST.  It's not clear to me whether this PoI has any significance
>when AIGP is used.

Ah, yes.

There are 3 cases. 

(1) AIGP is "executed BEFORE any of the tie-breaking procedures".  This is
just another step in the decision process, already covered in the POI
Table.

(2) AIGP replaces the IGP_COST and the Cost Community is examined *after*
that.  Nothing special here because we don¹t care what the value was at
the step before..

(3) AIGRP replaces the IGP_COST and the high-order bit is set.  In this
case both would try to replace the same value.  We added this text:

         If the Accumulated IGP Metric Attribute (AIGP) [RFC7311] is
         used such that the "AIGP-enhanced interior cost" replaces the
         "interior cost" tie breaker in the Decision Process, and the
         high-order bit is set with the IGP_COST POI, then the Cost
         Community SHOULD be ignored in favor of the process described
         in Section 4.2 of [RFC7311].






>d. AS_PATH.  Presumably if the high-order bit of the Community-ID is
>set, the length of the AS_PATH is not used as a tie breaker, but the
>AS_PATH would still be used to prevent loops.  If this interpretation is
>correct, that would be good to mention explicitly; othewise someone
>might assume that the AS_PATH is completely ignored in this case.

Yes, this may be a general interpretation issue.

NEW
         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.  For
         example, if the high-order bit is set with the AS_PATH POI, the
         AS_PATH attribute would still be used for loop prevention
         [RFC4271], but the Cost would replace its length in the
         Decision Process.




>e LOCAL_PREF.  If a route has both a LOCAL_PREF and a Cost Community
>with the LOCAL_PREF PoI, and if the high-order bit of the Community-ID
>is set, then the LOCAL_PREF would be ignored.  Is there a use case for
>this particular combination?

In that case, the result of using LOCAL_PREF or the Cost Community would
be the same.

>5. Security Considerations
>
>Considering the havoc that could be wreaked if a Cost Community gets
>improperly added or modified, through either error or malfeasance, it
>doesn't seem right to just say "no security considerations".

Yes, we rewrote this section to turn it off my default.


>6. Terminological Consistency
>
>It's a bit of a chore to figure out the relationship between "metrics",
>"attributes", "points of insertion", and "communities".  These terms do
>not appear to be used consistently through the document.  Terms like
>"tie breaker" and "degree of preference" do not appear to be used the
>same way they are used in RFC 4271.  Undefined terms like "generally
>equal paths" are used freely.  I think interoperability will be
>facilitated by a greater degree of precision and consistency in the
>terminology.

Point taken..we did a general edit of the document to be more consistent.


>
>
>Additional comments interspersed in the text, look for lines beginning
>with "Eric>".
>
>
>Inter-Domain Routing                                           A. Retana
>Internet-Draft                                       Cisco Systems, Inc.
>Intended status: Standards Track                                R. White
>Expires: October 22, 2015                                       Ericsson
>                                                           April 20, 2015
>
>
>                       BGP Custom Decision Process
>                    draft-ietf-idr-custom-decision-06
>
>Abstract
>
>    The BGP specification defines a Decision Process for installation of
>    routes into the Loc-RIB.  This process takes into account an
>    extensive series of path attributes, which can be manipulated to
>    indicate preference for specific paths.  It is cumbersome (if at all
>    possible) for the end user to define policies that will select, after
>    partial comparison, a path based on subjective local (domain and/or
>    node) criteria.
>
>Eric> I doubt that "subjective" is what is meant here; generally routing
>is based on objective criteria.  The above also seems to suggest that
>the criteria can be specific to a particular node; that seems strange,
>given the need for consistent routing within a domain.

NEW
   The BGP specification describes a Decision Process for selecting the
   best route.  This process uses a series of steps, made up of path
   attributes and other values, to first determine the Degree of
   Preference of a route and later as tie breakers.  While existing
   mechanisms may achieve some of the same results described in this
   document, they can only do so through extensive configuration such as
   matching communities to explicit policy and/or route preference
   configurations present on each BGP speaker within their
   administrative domain (autonomous system).  Implementing some
   specific fine grained policies through such mechanisms is cumbersome,
   if even possible.





>
>    This document defines a new Extended Community, called the Cost
>    Community, which may be used in tie breaking during the best path
>    selection process.  The end result is a local custom decision
>    process.
>
>
>1.  Introduction
>
>    There are a number of metrics available within the BGP decision
>    process [RFC4271] which can be used to determine the exit point for
>    traffic, but there is no metric, or combination of metrics, which can
>    be used to break a tie among generally equal paths.
>
>Eric> What is meant by "Generally equal paths"?
>
>Eric> RFC 4271 section 9.1.2.2 is called "Breaking Ties".  Yet the above
>suggests that there is no way to break ties.

NEW>
   The BGP specification defines a Decision Process [RFC4271] for
   selecting the best route.  This process uses a series of steps, made
   up of path attributes and other values, to first determine the Degree
   of Preference of a route and later as tie breakers.  While existing
   mechanisms may achieve some of the same results described in this
   document, they can only do so through extensive configuration such as
   matching communities to explicit policy and/or route preference
   configurations present on each BGP speaker within their
   administrative domain (autonomous system).  Implementing some
   specific fine grained policies through such mechanisms is cumbersome,
   if even possible.



>
>    o  LOCAL_PREF: The LOCAL_PREF is an absolute tie breaker near the
>
>Eric> RFC 4271 talks about LOCAL_PREF to establish the degree of
>preference, not to break ties.  In general, the terminology in this
>draft is not well-aligned with the terminology in section 9.1 of RFC 4271.
>
>       beginning of the decision process.  There is no way to configure
>       the LOCAL_PREF such that the MED, IGP metric, and other metrics
>       are considered before breaking a tie.
>
>Eric> I do not understand what this paragraph is trying to say.  I
>thought the whole point of LOCAL_PREF was to establish a degree of
>preference that does not take these other factors into account.

We did a general review to be in alignment and consistent.

NEW>
   o  Local Preference: The LOCAL_PREF is an attribute used to calculate
      the Degree of Preference in the Decision Process.  There is no
      secondary degree of preference indicator available that can be
      considered after the MED, IGP metric, or other attributes.





>
>    o  MED: The MULTI_EXIT_DISC is an indicator of which local entrance
>       point an AS would like a peering AS to use; MED isn't suitable to
>       break the tie between two equal cost paths learned from two peer
>       ASes.  MED is also compared before the IGP metric; there is no way
>       to set the MED so a path with a higher IGP metric is preferred
>       over a path with a lower IGP metric.
>
>Eric> I don't follow this; if MED is compared before the IGP metric is
>considered, why can't it cause a route with lower IGP metric to be
>eliminated from consideration while a route with higher IGP metric
>continues to be considered?  A route via a different peering AS will
>still be preferred if it has a lower IGP metric; is that what the above
>is trying to say?

What we were trying to say was that after the MED is compared, there's no
way to come back to it to indicate that a higher metric route is preferred.

>
>    o  IGP Metric: It is possible, using the IGP metric, to influence
>       individual paths with otherwise equal cost metrics, but only by
>
>Eric> It is really not clear what is meant by "otherwise equal cost
>metrics".

We meant that if the routes had the same next hop ("otherwise equal cost
metrics")...  In any case, we removed that phrase and think that it is
clearer now.

>
>       changing the next hop towards each path, and configuring the IGP
>       costs of reaching each next hop.  This method is cumbersome, and
>       prone to confusion and error.
>
>    The BGP specification defines a Decision Process for installation of
>    routes into the Loc-RIB.  This process takes into account an
>    extensive series of path attributes, which can be manipulated to
>    indicate preference for specific paths.  It is cumbersome (if at all
>    possible) for the end user to define policies that will select, after
>    partial comparison, a path based on subjective local (domain and/or
>    node) criteria.
>
>Eric> See comment above re "subjective criteria" and "node criteria".

Yes..clarified.

>
>...
>
>3.  The BGP Cost Community
>
>    The BGP Cost Community is an Opaque Extended Community [RFC4360]
>    defined as follows:
>
>    Type Field:
>       The value of the high-order octet of this Opaque Extended
>       Community is 0x03 or 0x43.  The value of the low-order octet of
>       the extended type field for this community is 0x01.
>
>Eric> Above should be brought into alignment with RFC 7153, as suggested
>at the start of this message.

Done.

>
>    Value Field:
>       The Value field contains three distinct sub-fields, described
>       below:
>
>
>                      +------------------------------+
>                      | Point of Insertion (1 octet) |
>                      +------------------------------+
>                      | Community-ID (1 octet)       |
>                      +------------------------------+
>                      | Cost (4 octets)              |
>                      +------------------------------+
>
>       The Point of Insertion sub-field contains the value of the path
>       attribute *after* which this community MUST be considered during
>       the best path selection process.
>
>
>
>          The BGP decision process includes some steps that do not
>          correspond to any path attribute; the following values are
>          defined:
>
>          128  ABSOLUTE_VALUE - Indicates that the Cost Community MUST be
>             considered as the first step in determining the Degree of
>             Preference of a path.
>
>          129  IGP_COST - Indicates that the Cost Community MUST be
>             considered after the interior (IGP) distance to the next-hop
>             has been compared.
>
>          130  EXTERNAL_INTERNAL - Indicates that the Cost Community MUST
>             be considered after the paths advertised by BGP speakers in
>             a neighboring autonomous system (if any) have been selected.
>
>          131  BGP_ID - Indicates that the Cost Community MUST be
>             considered after the BGP Identifier (or ORIGINATOR_ID
>             [RFC4456]) has been compared.
>
>       The Community-ID sub-field contains an identifier to distinguish
>       between multiple instances of the Cost Community.  The high-order
>       bit is reserved to indicate that the Cost Community MUST replace
>       the path attribute specified by the Point of Insertion during the
>       best path selection process.
>
>Eric> See above questions about the semantics of the Community-ID
>sub-field when the high-order bit does not have the same setting for all
>the communities at a given Point of Insertion.

Answered above.

>
>       The Cost sub-field contains a value assigned by the network
>       administrator and that is significant to the local autonomous
>       system.  The lower cost MUST be preferred.  The default value is
>       0x7FFFFFFF (half the maximum value).
>
>Eric> Is this supposed to be a 32-bit unsigned integer?  If so, that
>needs to be said.

Done.

>
>
>4.  Operation
>
>    The network administrator may use the Cost Community to assign a
>    value to a path originated or learned from a peer in any part of the
>    local domain.  The Point of Insertion MUST also be specified using
>    the values defined in Appendix A.
>
>Eric> Please define "local domain".

Clarified "local domain" > administrative domain = autonomous system

>
>    If a BGP speaker receives a path that contains the Cost Community, it
>    SHOULD consider its value at the Point of Insertion specified, when
>    calculating the best path [RFC4271].
>
>    If the Point of Insertion is not valid for the local best path
>    selection implementation, then the Cost Community SHOULD be silently
>    ignored.  Paths that do not contain the Cost Community (for a valid,
>    particular Point of Insertion) MUST be considered to have the default
>    value.
>
>Eric> If a path has the cost community for a particular PoI, I think the
>intention is that it is considered to have the default value for all
>Community-IDs that do not appear in the list of communities for that
>PoI.  This is never actually said anywhere.

Yes, we added that explicitly.

>
>    Multiple Cost Communities may indicate the same Point of Insertion.
>    In this case, the Cost Community with the lowest Community-ID is
>    considered first.  In other words, all the Cost Communities for a
>    specific Point of Insertion MUST be considered, starting with the one
>    with the lowest Community-ID.
>
>    If a range of routes is to be aggregated and the resultant aggregate
>    path attributes do not carry the ATOMIC_AGGREGATE attribute, then the
>    resulting aggregate SHOULD have an Extended Communities path
>    attribute which contains the set union of all the Cost Communities
>    from all of the aggregated routes.  If multiple Cost Communities for
>    the same Point of Insertion (and with the same Community-ID) exist,
>    then only the ones with the highest Cost SHOULD be included.
>
>    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 when running the selection process.
>
>5.  Deployment Considerations
>
>    The mechanisms described in this document may be used to modify the
>    BGP path selection process arbitrarily.  It is important that a
>    consistent path selection process be maintained across the local
>    Autonomous System to avoid potential routing loops.  In other words,
>    if the Cost Community is used, all the nodes in the AS that may have
>    to consider this new community at any Point of Insertion SHOULD be
>    aware of the mechanisms described in this document.
>
>Eric> It's not clear what "SHOULD be aware of the mechanisms" means.  Do
>all nodes in a "local domain" have to support the exact same set of PoIs?

We changed the text to this:

NEW>
   The mechanisms described in this document may be used to modify the
   Decision Process arbitrarily.  It is important that a consistent
   Decision Process be maintained across the local Autonomous System to
   avoid potential routing loops.  In other words, all the nodes in the
   AS that may have to consider the Cost Community at any POI MUST
   support the mechanisms described in this document.

   Any mechanism which allows the modification of the Decision Process
   is capable of forming persistent routing loops in the control plane.
   Network administrators deploying the Cost Community MUST ensure that
   each impacted router in the network supports them, including the POIs
   deployed within their network.  This is similar in scope to a network
   administrator who uses communities [RFC1997] combined with filters or
   other policies to modify the Decision Process of BGP speakers.
   Consistency must be enforced at an administrative level.



>
>
>6.  Security Considerations
>
>    This document introduces no new security concerns to BGP or other
>    specifications referenced in this document.
>
>Eric> This doesn't seem true.

Right..this is the new text.

NEW>
   This document defines a new Extended Community, called the Cost
   Community, which may be used to customize the Decision Process.  As
   such, the considerations outlined in [RFC4360] and [RFC4271] do not
   change.

   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.

   An ill-designed policy deployment using the Cost Community (e.g. one
   where there is no consistent POI support throughout the AS) may
   result in persistent routing loops that could result in loss of
   traffic.  The design and implementation of policies for best route
   selection are outside the scope of this document.



>
>7.  IANA Considerations
>
>    IANA is asked to assign the type values indicated in Section 3 to the
>    Cost Community in the BGP Opaque Extended Community registry
>    [BGP_EXT].
>
>Eric> Align with RFC 7311 as suggested above.

Done.

>
>    Section 3 also defines a series of values to be used to indicate
>    steps in the best path selection process that do not map directly to
>    a path attribute.  IANA is expected to maintain a registry for the
>    Cost Community Point of Insertion values.  Values 1 through 127 are
>    to be assigned using the "Standards Action" policy or the Early
>    Allocation process [RFC7120].  Values 128 through 191 are to be
>    assigned using the "IETF Consensus" policy.  Values 192 through 254
>    are to be assigned using the "First Come First Served" policy.
>    Values 0 and 255 are reserved for future use and SHOULD NOT be used.
>
>Eric> This last sentence should probably just be "Values 0 and 255 are
>reserved."

Yes.

>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr