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

[joel jaeggli <[e-mail]>]

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