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

[Eric C Rosen <[e-mail]>]

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."

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?

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."

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.

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?

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.

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

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?

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

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.

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?

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".

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.


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.

    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.

    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.

    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?

    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".

       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".

...

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.

    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.

       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.


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".

    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.

    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?


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.

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.

    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."