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

[joel jaeggli <[e-mail]>]

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.
> 
> 
>