[bess] Joel Jaeggli's No Objection on draft-ietf-bess-mvpn-extranet-07: (with COMMENT)

["Joel Jaeggli" <[e-mail]>]

Joel Jaeggli has entered the following ballot position for
draft-ietf-bess-mvpn-extranet-07: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the frank discussion in buenos Aires and the proposed
edits. 

I think they address the concerns raised in the opsdir review.

was: 

Discuss
 
Sue Hares performed the opsdir review. benoit holds the discuss for the
points she raised.

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.  

was 

discuss 

After further discussion related to the ops dir review, I'm going to have
to echo Benoit and the Opsdir reviewers concern.

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