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

["Alvaro Retana (aretana)" <[e-mail]>]

On 4/22/15, 3:53 AM, "Idr on behalf of [e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Bruno:

Hi!  Sorry for the long delay..

Since we missed the ID deadline, I'm attaching what will be version –07 and the diffs..along with specific answers to your comments below.

Thanks!!

Alvaro.


Hi all,

Please find below some comments on the document:

§ Abstract
*) “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.”
IMHO the sentence may be reworded. e.g. using a more factual/neutral orientation. (Alternatively, the document would need to elaborate on how much “cumbersome”/”impossible” is saved by using this new tool. (definitely not all IMO)).

Yes.

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

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.





§3.  The BGP Cost Community
*) “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.”
- My reading of “value of the path attribute” is http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2  Is this correct? Probably not as the IANA section of this draft propose a new/different registry for POI.

We put in a new sentence to clarify:

         This document creates a new Cost Community Point of Insertion
         Registry (Section 7.1) that includes the relevant path
         attributes and these other values.


 *) “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.”
“reserved” does not seem to be the best word given that the bit is not reserved (for future use) but specified in this document.

s/is reserved to indicate/indicates


 *) “Multiple Cost Communities may indicate the same Point of Insertion.  In this case, the Cost Community with the lowest Community-ID is considered first.”
Multiple cost communities may be received with the same Point of Insertion and the same Community-ID. Please specific which one is to be taken or the error handling.

The same Community-ID is OK as long as it comes from different peers — in the end the winner should be the one with the lowest cost.

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


NEW>
   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.  If multiple Cost Communities,
   for the same POI, with the same Community-ID are received for the
   same route from the same peer, then all except the one with the
   lowest Cost MUST be silently ignored.


§ 5.  Deployment Considerations
*) “It is important that a  consistent path selection process be maintained across the local  Autonomous System to avoid potential routing loops.”
How much important?
Given the (below) use of a few SHOULD (vs MUST) there is no real assurance that no routing loops will form:
- “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”
- “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.”

IMO, either :s/SHOULD/MUST in the 2 above sentence, or the document must discuss the conditions which are safe and the ones which are not.

*) “be  aware of the mechanisms described in this document” is not enough. It also needs to support the specific POI used.

Obviously avoiding loops is very important. ;-)

We also added some additional text.

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.”
Really?? That sentence would rather make me feel that this document is not ready for RFC publication.
IMO a real consideration of the security aspects should be done.

e.g. (for free):
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.


§ 7.  IANA Considerations
“Some of the values in this new registry match the values assigned in the BGP Path Attributes registry [BGP_PAR].  It is RECOMMENDED that an effort be made to assign the same values in both tables when applicable.”
If this is the goal
- both allocation policies should probably be the same.
- IMHO the draft should comment on the POI value already assigned to BGP attribute. Should they be considered “reserved” of free to use as “non applicable”?
- it could be discussed that POI 129 “IGP_COST” may best match BG Attribute 3 NEXT_HOP

We decided to completely decouple the two registries.


 § Appendix A.  Cost Community Point of Insertion Registry
*) It looks like this whole section should be in the IANA section, rather than an appendix.

Yes, we moved it.