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
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
