Early Review of draft-fang-l3vpn-virtual-pe-05
review-fang-l3vpn-virtual-pe-05-rtgdir-early-meuric-2014-11-12-00

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.