Sue: Hi! Can you please take a look at this?
Thanks! Alvaro. On 4/12/16, 3:29 PM, "Martin Vigoureux" <[email protected]> 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:[email protected]] *On Behalf Of *Eric C Rosen >> *Sent:* Tuesday, December 22, 2015 2:08 PM >> *To:* Susan Hares; 'Benoit Claise'; 'The IESG' >> *Cc:* [email protected]; 'John G. Scudder'; >> [email protected]; [email protected]; >> [email protected]; [email protected] >> *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. >> >> >> >> >> >> >> _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
