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

[Martin Vigoureux <[e-mail]>]

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