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
