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
