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

["Alvaro Retana (aretana)" <[e-mail]>]

Sue:

Hi!  Can you please take a look at this?

Thanks!

Alvaro.

On 4/12/16, 3:29 PM, "Martin Vigoureux" <[e-mail]> wrote:

>Dear all,
>
>we took the opportunity of this IETF meeting to discuss with Sue, Joel
>and Benoit, and with Eric.
>
>Sue has had two requests:
>1/ to add some text clarifying the encoding and processing of the
>Extended Communities this document is defining.
>Eric had already integrated this text in the document (v06) and more
>specifically in Sections 4.4.1, 4.4.2 (for the Extranet Source Extended
>Community) and 4.5 (for the Extranet Separation Extended Community). The
>text on RR fitted more naturally in 4.4.2 than in 4.4.1, thus the split.
>
>We have reviewed that with Sue and my understanding of our discussion is
>that this is acceptable.
>
>2/ to add some text covering risks of mis-configurations
>Eric has added the paragraph quite soon in the document (the Overview
>section), such that the reader is aware. Following Thomas' suggestion to
>enhance that text with other cases of incorrect configurations, Eric has
>also added some text to the Security Considerations section.
>Since the document describes a tool-set, rather than trying to describe
>all the possible usages of these tools, the preferred approach was to
>give a form of warning on risks of misconf.
>
>Our understanding is that the addition of this paragraph would meet
>Sue's expectations.
>
>Version 07, which incorporates the above, is available.
>
>Sue, please review the changes and let us know if our understanding is
>correct or not, and thus if you consider your points addressed.
>
>Thank you all
>
>Best regards,
>Martin & Thomas
>
>Le 23/12/2015 16:13, Susan Hares a écrit :
>> Eric:
>>
>> *To clear my objection to this draft*, please add these sections to make
>> it clear what the content of the BGP values and their handling.    We
>> disagree on what the BGP registry document states, but that point is not
>> worth holding up this document.  People can find the type and sub-type
>> fields in the registry.  What is not in the registry is a clear
>> description of the restrictions of the value field and handling.
>>
>> Placing the BGP Extended communities within the rest of the rules is
>> just unclear. Please put these two sections in and give the details in
>> this sections.
>>
>> As to the deployment section, you did not consider the text I offer
>> below and the suggested insertion in the security section.  Perhaps you
>> can consider that text in your next email.  On whether this deployment
>> section is ³DISCUSS² worthy, I am still communicating with Benoit and
>>Joel.
>>
>> I wish you the peace and joy of the Christmas season,
>>
>> Sue Hares
>>
>> =============
>>
>> Sections which must be added to clear my concerns
>>
>> ----------------------------------------------------------------
>>
>> *4.4.1 Extranet Source Extended Community *
>>
>>     To facilitate this, we define a new Transitive Opaque Extended
>> Community, the "Extranet Source" Extended Community.
>>
>>     The value field of this extended community is all zeros.
>>
>> *Restrictions: *This value field MUST be set  to zero upon origination,
>>   MUST be ignored upon reception and MUST  be passed unchanged by
>> intermediate routers.
>>
>> *Additional Restrictions: *A Route Reflector MUST NOT add/remove the
>> Extranet Source Extended  Community from the VPN-IP routes reflected by
>> the Route Reflector,  including the case where VPN-IP routes received
>> via IBGP are reflected to EBGP peers (inter-AS option (c), see
>> [RFC6513]   Section 10).
>>
>> *4.4.2 Extranet Separation Extended community *
>>
>> **
>>
>> We define a new Transitive Opaque Extended Community, the "Extranet
>> Separation" Extended Community.  This Extended Community is used only
>> when extranet separation is being used.
>>
>> *Restrictions:*  Its value field MUST be set to zero upon origination,
>> MUST be ignored upon reception, and MUST be
>>
>>     passed unchanged by intermediate routers.
>>
>> *  Restrictions on Adding/deleting this community:*  ??  (Eric ­ please
>> add something here).
>>
>> *Comments that could be put in a Security section: *
>>
>> **
>>
>> 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.
>>
>> *From:*BESS [mailto:[e-mail]] *On Behalf Of *Eric C Rosen
>> *Sent:* Tuesday, December 22, 2015 2:08 PM
>> *To:* Susan Hares; 'Benoit Claise'; 'The IESG'
>> *Cc:* [e-mail]; 'John G. Scudder';
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> *Subject:* Re: [bess] Benoit Claise's Discuss on
>> draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)
>>
>> On 12/22/2015 12:51 PM, Susan Hares wrote:
>>
>> Eric:
>>
>> Thank you for revisions in version -05 of your document.  Unfortunately
>> it does not resolve either of the two points I raised.
>>
>> 1)*On the BGP Extended Communities*, I feel your specification is
>> *unclear and warrants change on the DISCUSS* Criteria due to
>> interoperability issues.
>>
>>
>> I've explained why I don't think this is correct.  In particular, I
>> don't think it is wise to mention the value of the "Transitive Opaque
>> Extended Community Type" codepoint, as this can be found in the IANA
>> registry for Transitive Extended Community types, and implementers
>> should really be encouraged to consult the registries for the
>>codepoints.
>>
>>
>> 2)I¹ve given you 2 small sections to add to your document at the
>> beginning of section 4.4. to resolve this DISCUSS point.
>>
>>
>> Note that the codepoint you mention for Transitive Opaque Extended
>> Community Type is not correct.  Unnecessary last minute changes do tend
>> to introduce errors.
>>
>>
>> 3)You need to just fill in one part below on RR restrictions for
>> *Extranet Separation Extended community*.
>>
>>
>> I will add some text saying that RRs must not add or remove this EC.
>>
>>
>> 2) *On the deployment section:*  I given text and examples ­ but I think
>> you still misunderstand what I am looking for.
>>
>>
>> Perhaps.
>>
>>
>> Since you are an author of academic papers,
>>
>>
>> I am not.
>>
>>
>> consider I am looking for an operator-based ³abstract² that focuses the
>> reader on the key points.I am sure you can create one for this document,
>> but I not clear why you object to it the concept.
>>
>>
>> It seems to me that you are asking for something that could be titled
>> "An Operator's Guide to Provisioning Extranet MVPN".  While that might
>> be useful, it is not within the scope of the current document.  As I've
>> said, I am not aware of any IETF requirement that requires such a thing
>> to be included.
>>
>>
>> will you please let me know that you have read my suggested text
>> insertions on both these topics.
>>
>>
>> I have.
>>
>>
>>
>>
>>
>>
>>