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

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

Sue,

With regard to the issues re extended communities, you say "I cannot 
tell from your description what fields exist or the values in these two 
communities".

Per RFC 4360, an EC consists of a type field, possibly a sub-type field, 
and a value field.  The two ECs are defined to be Transitive Opaque 
Extended Communities.  Per RFC 7153, the codepoint to place in the type 
field of a Transitive Opaque Extended Community can be found in the IANA 
registry "BGP Transitive Extended Community Types".  Also per RFC 7153, 
the codepoints to placed in the sub-type field of a Transitive Opaque 
Extended Community can be found in the IANA registry "Transitive Opaque 
Extended Community Sub-Types", and the document requests IANA to make 
these two sub-type assignments. The text of the extranet draft says, in 
both cases, that the value field is to be set to zero.  Thus the fields 
and values are already clearly specified.  However, I did neglect to add 
normative references to RFC 4360 and RFC 7153.

I will add normative references to both RFC 4360 and RFC 7153 to the 
sections defining the two new ECs.

I'll modify the text a bit to make it clearer that the value field of 
the ECs MUST be set to zero, MUST be left unchanged during propagation, 
and MUST be ignored upon reception.

With regard to deployment considerations ...

Sue> What is necessary for the OPS/NM directorate review is a summary 
deployment section to guide operations on deployment tools, tips, and 
constraints.

I am not aware of any IETF requirement to include such a section.

Sue> Management of OAM overlays is a necessary part of understanding a 
protocol which is based 50+ pages of rules.  Do you believe this 
protocol can operate without standard monitoring or provisioning tools?

Certainly the protocol can operate without standard tools.  Numerous 
deployments of Extranet MVPN have been operating for years without 
standard tools.  Whether provisioning and/or monitoring tools need to be 
standardized is orthogonal to anything in this document.

It might be nice for operators to have tools to verify whether their 
provisioning and their device configurations have been done correctly, 
but the design of such tools is certainly outside the scope of this 
document.

Sue> you indicate that if the rules/constraints in this complex overlay 
of rules are violated (p. 11, 12, 19), and especially p. 19 in section 
2.3.2 which indicates a priori knowledge, inability to detect.

Whenever a VPN is provisioned, there is a risk that provisioning errors 
will result in an unintended cross-connection of VPNs, which would 
create a security problem for the customers.  Extranet can be 
particularly tricky, as it intentionally cross-connects VPNs, but in a 
manner that is intended to be strictly limited by policy.  If one is 
connecting two VPNs that have overlapping address spaces, one has to be 
sure that the inter-VPN traffic isn't to/from the part of the address 
space that is in the overlap.  The draft discusses a lot of the corner 
cases, and a lot of the scenarios in which things can go wrong.  But it 
is not intended to be an "operator's guide to provisioning and 
configuring extranet MVPN."

With regard to section 2.3.2, the point is the following.  If one is 
deploying hardware that cannot implement the "discard multicast flows 
that are received on the wrong tunnel" procedures, then one has to 
provision the extranet to limit the ways in which multiple flows can be 
aggregated into a single tunnel.  Section 2.3.2 also points out that one 
cannot tell from inspection of the control messages whether this 
provisioning has been done correctly. Operators worried about whether 
their provisioning systems are up to the task may choose to deploy 
equipment that can do the "discard multicast flows from the wrong 
tunnel" procedures.

Sue> What is necessary for the OPS/NM directorate review is a summary 
deployment section to guide operations on deployment tools, tips, and 
constraints.  3+ paragraphs in 1 section.

I'm still perplexed about what you are asking for, or about what you 
think these "3 paragraphs" would say.  The draft has extensive 
discussion of deployment constraints.  There is no IETF requirement for 
a document of this sort to include a "tips and tools" section; that is 
clearly out of scope.

Eric