On 2/25/16 1:25 PM, Eric C Rosen wrote: > 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.
Yeah, I'm not convinced of that, there is eleborate discussion of the
requirement for one RD per VRF and then extranet seperation adds a twist
that.
However, when Extranet Separation is used, some of
the local-RD routes exported from the VRF will contain the extranet
RD. Details concerning the exported routes that contain the extranet
RD can be found in Sections 4.1 and 7.3.
> 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.
>
>
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
