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

[<[e-mail]>]

1 possible additional comment

§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]. »

I'm not sure that you need to ask anything to the IANA given that this part of the registry is First Come First Served and that the values have already been registered:
http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-opaque
http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#non-trans-opaque

Regards,
Bruno


From: Idr [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, April 22, 2015 11:54 AM
To: Susan Hares
Cc: [e-mail]
Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

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

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

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

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

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

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


§ 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

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


Thanks,
Regards,
Bruno

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Monday, April 20, 2015 9:34 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

This begins a 2 week WG LC for the following draft:

http://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision


The authors should comment on the existence of IPR on the list, and the availability of implementations.  A set of questions for this WG LC are:


1)      Is this custom-decision useful in networks?

2)      Is there any concern regarding standardization or deployment regarding this standard?

3)      Do you know if interoperable implementations? If so, can you share your experience regarding the interoperability.

As always, it is important to indicate "support" or "no support" for the WG LC.

Sue Hares and John Scudder

_________________________________________________________________________________________________________________________



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,

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

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.