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

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

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.