I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments 
just like any other last call comments.

Abstract: This document investigates the use of EBGP as stand-alone routing protocol for large-scale data centers instead of traditional DC designs in which layer 2 or layer 2/layer 3 based solutions are used.
Intended for: Informational RFC
Status:  Ready to be published , no NITS

The review was asked for -09 but -10 has been published in the meanwhile. I've used this version for the review.

This document is for information and does not require IANA action. At this stage, I think that the document is ready for publication. 
I have read this document as the newbie that I am in the domain of DC and use of BGP. The document is well-written and I've succeeded to understand the main principles, that is a very good point :)

I don't know if there are some other comments during the IESG that will require the publication of a new version of the draft. If there are, please find hereafter some thoughts that could/might be taken into account when drafting the new version. Please feel free to ignore them if not relevant.

Regards,

Lionel

*************************************

This document is intended for people familiar with operational aspects in large-scale DC and the use of EBGP. As a consequence, some aspects discussed in the document are not so well detailed as it is assumed that the reader is familiar with, that may not be the case. An advertisement could be added in the introduction to indicate the pre-requisite knowledge to use this document, with suitable list of references.

The set of network design requirements for large-sale DC given in the document is generic enough to be understand by anyone but it is not clear if all the requirements have to be fulfilled or if there is a preference order implied by the requirements ordering. 

if the tree based design of traditional DC is presented, there is no description of the shortcomings of such a design, especially regarding the requirement compliance. In the rest of the document, it is assumed that an horizontally scalable topology is required to meet REQ1, by opposition to traditional tree-based design. It could be interesting to have this conclusion in the section describing the traditional DC topology.

In the section providing the Data Center Routing Overview, if the limitations of L2 only design and the advantages of L3 only designs are quite well described, the case of hybrid L2/L3 design is not so well described. Except when it is said, "This design has allowed data centers to scale up, but at the cost of complexity in managing multiple network protocols.". It is not clear if the complexity cost is acceptable compared to the benefits (cf. comment above on requirement trade-off).

I'm not so sure why the section 5 is entitled "Routing Protocol Selection and Design" whereas this section only deals with EBGP and there is therefore no selection.

In the rest of the document, it appears that the choice of EBGP as only routing protocol implies a number of limitations and workarounds/options are proposed to overcome these issues, e.g.: 

- Support of "Allowas-in" feature or Four-Octet ASNs to overcome the limitation of use of Private Use ASNs
- Mechanisms (e.g. route summarization) to minimize the number of routes to advertize into BGP
- Network topology hiding to remove Private Use ASNs from the AS_PATH attribute
- Support of support of wider ECMP for large multipath fan-out or logical link-grouping to provide "hierarchical" ECMP
- Support of load sharing over multiple ASNs, etc.

However, it often depends on "feature availability" and part of the proposed solutions are not standardized. For some issues, two or more alternatives are proposed, without any specific preference between them. As a consequence, at the end of the document, the reader could be puzzled with the different options and will have to figure out which design options to use, based on availability in the products.
As it is said that this document is based on experimentation and extensive testing, it could be good to find a "recommended/preferred" network design for use of EBGP in large-scale DC as a conclusion of the document, based on current state-of-the-art and assumed/known availability of the different options. This conclusion could be used to list any standard action (if any identified) that would be required to ensure a general adoption of EBGP as routing protocol in large-scale DC.

_________________________________________________________________________________________________________________________

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.