Telechat Review of draft-ietf-rtgwg-bgp-routing-large-dc-09
review-ietf-rtgwg-bgp-routing-large-dc-09-opsdir-telechat-morand-2016-06-13-00

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.