[RTG-DIR] Routing Directorate QA Review of draft-fang-l3vpn-virtual-pe-05

[<[e-mail]>]

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.