Early Review of draft-fang-l3vpn-virtual-pe-05
review-fang-l3vpn-virtual-pe-05-rtgdir-early-meuric-2014-11-12-00
Review
review-fang-l3vpn-virtual-pe-05-rtgdir-early-meuric-2014-11-12
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.