On 2/24/2016 6:14 PM, joel jaeggli wrote:
Providing
operational advice isn't in scope? Section 1.3 goes into detail to the
point where it is hard to parse the application of route distinguishers.
Anyone who understands the normative references will know what a Route
Distinguisher is and what a VRF is. The fundamental part of
provisioning any RFC4364 VPN is to create the VRFs, and to provision
each VRF with Route Distinguishers.
Section 1.3 states that, for the purposes of MVPN, two VRFs MUST NOT be
configured with the same RD.
It further states that if the "extranet separation" feature is not
required, every VRF MUST be configured with a single RD. If the feature
is required, every VRF MUST be configured with two RDs, one called the
"default RD" and one called the "extranet RD".
In other words, that entire section specifies requirements that must be
met by whatever process is used to provision the MVPN extranet. It also
specifies reasons why these requirements are in place by mentioning some
of the situations in which the protocols presuppose that these
provisioning requirements are met.
I don't see what's missing. I find it puzzling that a section whose
whole purpose is to clarify the provisioning requirements (and the
dependencies of the protocols on those requirements) would be held up as
an example of how there are no operational considerations.
It's true that the section is more focused on providing a precise
description of the provisioning requirements than on providing a
tutorial or guide or "advice". But the former is within the scope of
the document and the latter is not. After all, the purpose of this
document is to specify the protocols and procedures that need to be
implemented. The purpose is not to define a service model or
provisioning system.
extranets are by the nature set up by two independent entities. one
presumes both mutual cooridnation, and design efforts required to avoid
collisions.
Extranet involves two VPNs, but the provisioning of the extranet is
generally done by the single service provider that is providing both of
those VPNs. Thus the provisioning of an extranet generally does not
require coordination between two independent entities.
It is possible that two independent providers will coordinate to provide
an extranet, but it is also possible that two independent providers will
coordinate to provide a single VPN, if that single VPN has sites
attached to both providers.
For this reason, RFC4364 defines the Route Targets in such a way as to
enable service providers to allocate globally unique Route Targets.
The need for uniqueness of the Route Targets is not specific to extranet
or to multicast, and is covered in the normative references.
the concerns in 2.3.2
Section 3 of this document describes a procedure known as "extranet
separation". When extranet separation is used, the ambiguity of
Section 2.1 is prevented. However, the ambiguity of Section 2.2 is
not prevented by extranet separation. Therefore, the use of extranet
separation is not a sufficient condition for avoiding the procedures
referenced in Section 2.3.1. Extranet separation is, however,
implied by the policies discussed in this section (Section 2.3.2).
so being prescriptive with respect to how these may be operated seems
like it would be helpful.
The draft goes into excruciating detail about how to avoid address
ambiguity when moving data between two VPNs that have overlapping
address spaces. It specifies a protocol-based mechanism ("discard from
the wrong tunnel") allows you to determine which of two streams is the
one you want, even if both streams use the same IP addresses. It also
specifies policies, for assigning multicast flows to tunnels, that can
be used to avoid address ambiguity.
Again, I don't see what is lacking.
Note that there is no requirement to have a separate "operational
considerations" section.
nor would that I think be necessary to address the concern.
Perhaps someone could explain to me exactly what is necessary to address
the concern.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
