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 given you 2 small sections to add to your document at the beginning of section 4.4. to resolve this DISCUSS point. You need to just fill in one part below on RR restrictions for Extranet Separation Extended community. 2) On the deployment section: I given text and examples – but I think you still misunderstand what I am looking for. Since you are an author of academic papers, 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. The “security consideration ” in section 10 in the text use “security consideration” as a euphemism for the traffic being sent to the wrong place. This is deployment and security issue – not just a security consideration. The third paragraph of your text in section 10 starting with “In general, different VPNs are allowed to have overlapping IP address” needs to clearly state what you stated to me in this last email. (see the text below). To limit the email back-forth, will you please let me know that you have read my suggested text insertions on both these topics. I will email Benoit/Joel offline regarding #2 deployment to see if he believes it is not a DISCUSS criteria. Cheerily, Sue ============== BGP Communities text to resolve comment: =================== 4.4.1 Extranet Source Extended Community To facilitate this, we define a new Transitive Opaque Extended Community, the "Extranet Source" Extended Community. (high-type field is 0x43, sub-type: TBD). 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 (high-type field is 0x43, sub-type: TBD). 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. -----Original Message----- From: Eric C Rosen [mailto:[email protected]] Sent: Monday, December 21, 2015 2:59 PM To: Susan Hares; 'Benoit Claise'; 'The IESG' Cc: [email protected]; [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) Sue, With regard to the issues re extended communities, you say "I cannot tell from your description what fields exist or the values in these two communities". Per RFC 4360, an EC consists of a type field, possibly a sub-type field, and a value field. The two ECs are defined to be Transitive Opaque Extended Communities. Per RFC 7153, the codepoint to place in the type field of a Transitive Opaque Extended Community can be found in the IANA registry "BGP Transitive Extended Community Types". Also per RFC 7153, the codepoints to placed in the sub-type field of a Transitive Opaque Extended Community can be found in the IANA registry "Transitive Opaque Extended Community Sub-Types", and the document requests IANA to make these two sub-type assignments. The text of the extranet draft says, in both cases, that the value field is to be set to zero. Thus the fields and values are already clearly specified. However, I did neglect to add normative references to RFC 4360 and RFC 7153. I will add normative references to both RFC 4360 and RFC 7153 to the sections defining the two new ECs. I'll modify the text a bit to make it clearer that the value field of the ECs MUST be set to zero, MUST be left unchanged during propagation, and MUST be ignored upon reception. With regard to deployment considerations ... Sue> What is necessary for the OPS/NM directorate review is a summary deployment section to guide operations on deployment tools, tips, and constraints. I am not aware of any IETF requirement to include such a section. Sue> Management of OAM overlays is a necessary part of understanding a protocol which is based 50+ pages of rules. Do you believe this protocol can operate without standard monitoring or provisioning tools? Certainly the protocol can operate without standard tools. Numerous deployments of Extranet MVPN have been operating for years without standard tools. Whether provisioning and/or monitoring tools need to be standardized is orthogonal to anything in this document. It might be nice for operators to have tools to verify whether their provisioning and their device configurations have been done correctly, but the design of such tools is certainly outside the scope of this document. Sue> you indicate that if the rules/constraints in this complex overlay of rules are violated (p. 11, 12, 19), and especially p. 19 in section 2.3.2 which indicates a priori knowledge, inability to detect. 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. But it is not intended to be an "operator's guide to provisioning and configuring extranet MVPN." With regard to section 2.3.2, the point is the following. If one is deploying hardware that cannot implement the "discard multicast flows that are received on the wrong tunnel" procedures, then one has to provision the extranet to limit the ways in which multiple flows can be aggregated into a single tunnel. Section 2.3.2 also points out that one cannot tell from inspection of the control messages whether this provisioning has been done correctly. Operators worried about whether their provisioning systems are up to the task may choose to deploy equipment that can do the "discard multicast flows from the wrong tunnel" procedures. Sue> What is necessary for the OPS/NM directorate review is a summary deployment section to guide operations on deployment tools, tips, and constraints. 3+ paragraphs in 1 section. I'm still perplexed about what you are asking for, or about what you think these "3 paragraphs" would say. The draft has extensive discussion of deployment constraints. There is no IETF requirement for a document of this sort to include a "tips and tools" section; that is clearly out of scope. Eric
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
