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

[<[e-mail]>]

Hi Alvaro,

Thanks for considering my comments.
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.


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

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.

---

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


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


--

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

Thanks,
Regards,
Bruno


From: Alvaro Retana (aretana) [mailto:[e-mail]]
Sent: Monday, October 26, 2015 5:59 PM
To: DECRAENE Bruno IMT/OLN
Cc: [e-mail]; Susan Hares
Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

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.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.