Last Call Review of draft-ietf-bess-mvpn-extranet-04
review-ietf-bess-mvpn-extranet-04-opsdir-lc-hares-2015-12-22-00

Eric, Rahul, Yiqun, and Thomas:



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.



Please let me know if any of these comments are unclear.  This is interesting
BESS work, and a clear deployable specification will help with multicast
traffic (video and other traffic).



Sue Hares



======



Status: Not ready,  three major concerns and two editorial nits:



Major concerns:

1)



Specification of the Extranet Source Extended Community and Extra Source
extended Community



Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, and
3.3.



2)



Why is there no Deployment considerations section?



The whole draft is a set of rules for handling policy, BGP A-D routes, tunnel
set-up, and PIM Join/leaves in the case of an intra net.  Unless these rules
are followed exactly, traffic may flow into a VPN it is not suppose to.



If the customer and the SP must coordinate on setting up filters, the procedure
is outside the document.

An error in any of these set-ups is considered a “security violation”.



Milo Medin stated “with enough trust” a rock can fly to the moon.  However, the
NASA flights were fragile and risky.  In the journey to the moon, there was no
other choice.  Instrumentation has 4-5 backups.



In this set-up, one has to ask “is there another choice” to this whole design
that seem fragile addition of extranets to an intra-AS multicast design.  If
the design is not fragile, then there should be a deployment section indicating
how to manage the RTs, RDs, and policy set-up.  Perhaps experience with the
Intra-As has shown deployment tips that would make this less fragile.  If so, 
it would be good to include an operations consideration section.



If a new class of tools provides monitoring or provisioning, mentioning these
would be useful.  If yang modules are being developed, that would be useful.



Places that indicate issues with violated constraint:



p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25 last
paragraph (violation of constraints will cause things to not work.  However,
only policy can control), p. 27 4.2.2 (1

st

 paragraph, Route Reflector must not change), p. 31 (5.1, first paragraph),



3)



Is security section really a security section? It seems more like “do this
policy” or this will fail.  It should get a stronger review from the security
directorate



Editorial suggestions:



Summary: In general the authors provide dense English text to describe this
rules.   In general the English text contains valid complex sentences. 
However, a few things should be suggested:



1)



PTA – define it in a definition section or spell out the abbreviation

2)



Phrases like  “the RT RT-R” become overly dense.  Use “Route Target RT-R”.

3)



Breaking up section 6.2.1 – with subjection and subtitles would make it more
readable,

4)



P. 36 second paragraph.  The reason for the “MUST” in 1

st

 full paragraph is a bit vague.  It seems logical, but the reasoning is just
 vague in the text.

5)



paragraph 2 in page 47 (section 7.3.1) is awkward, please reword.

6)



Paragraph 5 in page 47 (section 7.3.1) – does not explain why the condition
should hold.  The authors have done this in eac other case, so it seems
inconsistent.

7)



Page 53 – section 7.4.5 paragraph 3  “VRF route Import EC” – please spell out
first usage and give abbreviation (VRF Route Import Extended Community (EC).