Hello,



I have been selected as the Routing Directorate QA reviewer for this 


draft. For more information about the Routing Directorate, please see 


€‹

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir








At this stage, the intend of the following is not to discuss the WG's 


decision about the I-D, but rather to help improving its content.




Summary



Globally, the I-D is easy to read and gathers some interesting 


information, but some work is still needed. The aim of the I-D is not 


clear along the document and hesitates between vPE requirements (e.g., 


I-D title, or section 1.2) and DC network design (e.g., unnecessary 


extensive details about vRR, or "it is worth the effort to study the 


traffic pattern and forwarding looking trend in _your own_ unique Data 


Center"). What is more, I do not get why it is marked as Standard Track: 


even though it includes an IANA section, the latter remains empty and 


the text remains a high level description without protocol specification.





Leaving the nits out at this stage, just a few more specific comments below.



- On the front page, the list of authors is impressive. However, two 


columns of names does not fit with guidelines from RFC 7322. The levels 


of commitments of authors will need to be distinguished.


- The word "CAN" used a couple of times is not part of RFC 2119 


keywords, it may be replaced by "can" or "MAY", depending on the intend.


- Still 2119-related, in section 5.1, the word "SHOULD" seems to mean 


"are very likely to", thus capitalization looks inappropriate.


- Over the 1st half of the document, the possibility to implement a vPE 


"in a server or a ToR" is mentioned every 2nd page: is it really the 


main message to be repeated in such an I-D?



- Sections 5, 6, 7 loose some focus on vPCE and are less clear. E.g.:


  * The 2nd scenario in section 6 looks like a cumbersome wording to 


define a L3 gateway connecting a L2 domain; whether the CE is virtual or 


not seems orthogonal.


  * Section 7.2 tries to summarize I2RS work, therefore that text will 


soon be outdated: pointing directly to I2RS would do a better job.


- I read in section 7.2 : "The protocols SHOULD be [...] familiar by the 


computing communities". I am afraid I should warn against this kind of 


statement: it is not a technical requirement and would even prevent from 


considering BGP in DCs (or, e.g. in other contexts, any effort on GMPLS).


- The security section should not wait for the full maturity of the I-D 


to be worked on; e.g., the access to the interconnected vPE-C or the 


(v)CE is not mentioned.




Regards,

Julien


_________________________________________________________________________________________________________________________

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.