Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen <[e-mail]>]

Draft-ietf-bess-mvpn-extranet-05 has been posted.

This revision contains some edits to the sections on the Extended 
Communities, and some other editorial changes, stemming from the ops-dir 
review.

I did not follow the suggestion of the ops-dir review to add an 
"Operator Tips and Tricks" section, as that would be outside the scope 
of the document, and there is no IETF requirement to include such a section.

On 12/17/2015 8:30 AM, Benoit Claise wrote:
> Benoit Claise has entered the following ballot position for
> draft-ietf-bess-mvpn-extranet-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> As mentioned in Sue Hares' OPS DIR, 3 major concerns. The last one is
> actually for the security ADs.
>
> 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 (1st 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
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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 1st 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).
>
>