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

From: joel jaeggli <[email-masked]>
Date: Wed, 24 Feb 2016 15:14:25 -0800

Hi,  I've reviewed this again in light of our discussion during the IESG
review. From my vantage point discussion on this document is intended to
address corner cases, as is the document itself since inter-vpn exchange
of multicast traffic is itself (in particular for asm) a corner-case,
I'm not sure I suscribe to the rairty of asm vs ssm but for the
appication described, ok .

n 1/27/16 10:35 AM, Eric C Rosen wrote:
> On 1/27/2016 4:37 AM, Benoit Claise wrote:
>>
>> This document doesn't give an operator “so-what” for deployment in 60
>> pages.
> I'm afraid I don't understand this sentence.
> 
>> You know, a few summary paragraphs that indicates where this
>> specification is useful and where it is not for operators, and the
>> potential fragility of the solution (which could be in a new
>> operational consideration section or in the security considerations.
> As I've been trying to explain to Sue, I don't understand what is being
> asked for in these "few summary paragraphs".   An "operator's guide to
> provisioning extranets" would be useful, but not within the scope of
> this draft.

I'm having a little trouble parsing where you disagree. 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.

> The security considerations section already points out that
> misconfiguration of the Route Targets may result in misdelivery of
> traffic; the above text is merely a paraphrase of material that is
> already present in the document.
> 
> Note that there is no requirement to have a separate "operational
> considerations" section.

nor would that I think be necessary to address the concern.

>> I don't think I've seen text around coordination to set up filter, for
>> example.
> Coordination to set up filters?  I don't know what you are referring to.

extranets are by the nature set up by too independant entities. one
presumes both mutual cooridnation, and design efforts required to avoid
collisions.

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.

>>
>> Sue has been trying to be helpful and even proposed some text:
>>
>>     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. 
>>
> 
> Actually, I wrote that text in an email to Sue.  Although it too is just
> a paraphrase of existing materiaI, I could add it to the "overview"
> section as part of the description of what an extranet is.   Are you
> saying that you will lift the DISCUSS if I just add that paragraph? 
> 
> 
>

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 25 Feb 2016 16:25:16 -0500

On 2/24/2016 6:14 PM, joel jaeggli wrote:
> Providing
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
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.

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

---

From: joel jaeggli <[email-masked]>
Date: Sun, 28 Feb 2016 08:36:34 -0800

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