Re: [bess] AD Review of draft-ietf-bess-mvpn-extranet-03
On 11/17/15, 4:33 PM, "Eric C Rosen" wrote: >[Eric] Alvaro, thanks for your review. I just posted revision -04, >with a number of edits made in response to your comments. Thanks! I've requested IETF Last Call and put the document on the Telechat agenda. Alvaro. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] AD Review of draft-ietf-bess-mvpn-extranet-03
On 11/12/2015 2:50 PM, Alvaro Retana (aretana) wrote: Hi! I just finished reading this document. [Eric] Alvaro, thanks for your review. I just posted revision -04, with a number of edits made in response to your comments. As mentioned by the WG chairs at the meeting in Yokohama, the technology in bess can be complex and hard to penetrate for the average (or novice) reader. While the target of documents like this one is not always the average (or novice) reader, it is important that those readers (including the IESG and other review directorates) are able to at least understand what's going on. [Eric] Often, reviewers from various directorates are assigned documents that they are not qualified to review. This is certainly a problem, but not a problem with the documents. There is also a problem with certain ADs (NOT routing area ADs of course) who don't know nearly as much as they think they do. Well, luckily for them, bidirectional multicast is not discussed in this document, as it really seems to freak them out! Because of the length of the document, it would be nice to include a "road map" to guide the reader (in general: "Section x talks about X, Section y covers Y, etc."). It might be easier to include references to the specific sections in 1.4 (Overview). [Eric] I think the table of contents is as good a road map as we are going to get. Adding additional pointers to the overview doesn't provide additional value, and most likely would just introduce errors. This is a long standards track document, so it is bound to have a lot of normative language. On one hand I don't want to go overboard with explicitly mandating every little step..but at the same time we want to be clear as to what is "actually required for interoperation or to limit behavior which has potential for causing harm" [RFC2119]. Due to the potential of bad configurations resulting in incomplete/illdefined extranets, I can see why the behavior around RTs would require normative language. However, there are some places where the use of rfc2119 keywords may be lacking, not needed or inconsistent. An example of inconsistency is this paragraph from Section 7.2.3.1. (When Inter-Site Shared Trees Are Used): If VRF-S exports a Source Active A-D route that contains C-S in the Multicast Source field of its NLRI, and if that VRF also exports a UMH-eligible route matching C-S, the Source Active A-D route MUST carry at least one RT in common with the UMH-eligible route. The RT must be chosen such that the following condition holds: if VRF-R contains an extranet C-receiver allowed by policy to receive extranet traffic from C-S, then VRF-R imports both the UMH-eligible route and the Source Active A-D route. .. If the "route MUST carry at least one RT", why isn't the condition to be met also normative? I don't want to belabor on this specific case, it is just an example. [Eric] I think you are right about this case; I've fixed the text. However, I would appreciate it if the authors would scan the document for required or unneeded normative language. I pointed at some cases in my comments below. [Eric] I looked at each of the 200 or so occurrences of "must", "should", etc., and made some changes. I think it's more consistent now, but the criteria for when to say "MUST" and when to say "must" have never been very clear. I do have a couple of items that I think are Major (see below) that I would like to see addressed before starting the IETF Last Call. Major: 1. Section 1.3. (Clarification on Use of Route Distinguishers) uses the word "REQUIREs" in a couple of places. In a strict manner, the rfc2119 key words is "REQUIRED". While I think that the meaning of using "REQUIREs" should be obvious, please rephrase the text to strictly use the rfc2119 language. [Eric] I changed "this document REQUIREs" to "it is REQUIRED by this document". Hopefully, the RFC editor won't ding me for unnecessary use of the passive voice ;-) 2. Section 10 (Security Considerations) * What is a "VPN security violation"? It is mentioned in several places, but it is not explicitly defined. Please either add a reference or be clear in what it is. [Eric] A "VPN security violation" is just any situation in which a packet gets delivered to a VPN where it isn't supposed to go. I added a definition in the terminology section, and also in the Security Considerations section. * Misconfiguration is a significant risk, for example assigning the wrong RTs to the wrong routes. I think that risk should be mentioned. [Eric] This is generally true of any technology based upon RFC4364. I added a sentence about this to the Security Considerations. Minor: 1. Section 1.1. (Terminology): "We will sometimes say that a route "matches" a particular host if the route matches an IP address of the host." Given the previous definiti
[bess] AD Review of draft-ietf-bess-mvpn-extranet-03
Hi!
I just finished reading this document.
As mentioned by the WG chairs at the meeting in Yokohama, the technology in
bess can be complex and hard to penetrate for the average (or novice) reader.
While the target of documents like this one is not always the average (or
novice) reader, it is important that those readers (including the IESG and
other review directorates) are able to at least understand what's going on.
Most of my comments (below) are around readability/clarity.
In general I found the document (relatively) not hard to follow, if you read it
end-to-end — it may be harder for someone to jump in and read/review a specific
section without the benefit of building up to it.Because of the length of
the document, it would be nice to include a "road map" to guide the reader (in
general: "Section x talks about X, Section y covers Y, etc."). It might be
easier to include references to the specific sections in 1.4 (Overview).
This is a long standards track document, so it is bound to have a lot of
normative language. On one hand I don't want to go overboard with explicitly
mandating every little step..but at the same time we want to be clear as to
what is "actually required for interoperation or to limit behavior which has
potential for causing harm" [RFC2119]. Due to the potential of bad
configurations resulting in incomplete/illdefined extranets, I can see why the
behavior around RTs would require normative language. However, there are some
places where the use of rfc2119 keywords may be lacking, not needed or
inconsistent. An example of inconsistency is this paragraph from Section
7.2.3.1. (When Inter-Site Shared Trees Are Used):
If VRF-S exports a Source Active A-D route that contains C-S in the
Multicast Source field of its NLRI, and if that VRF also exports a
UMH-eligible route matching C-S, the Source Active A-D route MUST
carry at least one RT in common with the UMH-eligible route. The RT
must be chosen such that the following condition holds: if VRF-R
contains an extranet C-receiver allowed by policy to receive extranet
traffic from C-S, then VRF-R imports both the UMH-eligible route and
the Source Active A-D route.
.. If the "route MUST carry at least one RT", why isn't the condition to be met
also normative? I don't want to belabor on this specific case, it is just an
example. However, I would appreciate it if the authors would scan the document
for required or unneeded normative language. I pointed at some cases in my
comments below.
I do have a couple of items that I think are Major (see below) that I would
like to see addressed before starting the IETF Last Call.
Major:
1. Section 1.3. (Clarification on Use of Route Distinguishers) uses the word
"REQUIREs" in a couple of places. In a strict manner, the rfc2119 key words is
"REQUIRED". While I think that the meaning of using "REQUIREs" should be
obvious, please rephrase the text to strictly use the rfc2119 language.
2. Section 10 (Security Considerations)
* What is a "VPN security violation"? It is mentioned in several
places, but it is not explicitly defined. Please either add a reference or be
clear in what it is.
* Misconfiguration is a significant risk, for example assigning the
wrong RTs to the wrong routes. I think that risk should be mentioned.
Minor:
1. Section 1.1. (Terminology): "We will sometimes say that a route "matches"
a particular host if the route matches an IP address of the host." Given the
previous definition (in the same paragraph) of "match" ("the address prefix of
the given route is the longest match in that VRF for the given IP address") and
the use of match there makes it unclear whether you're talking about a host
route or just the longest match.
2. Section 1.3. (Clarification on Use of Route Distinguishers)
* This section explains the "unique VRF per RD" condition a couple of
times — even though the explanation seems to be the same, it would be nice if
it was explained only once.
* ""default RD" (discussed above)" Where this text appears is in fact
the first time that a "default RD" is mentioned. I'm guessing that this refers
to the RD in the "unique VRF per RD" condition, but please don't make the
reader guess.
3. Section 4.1. (UMH-Eligible Routes) The "MAY" in the second paragraph
appears to be part of the example. Suggested new text:
* The UMH-eligible extranet C-source routes do not necessarily have to
be unicast routes, they MAY be SAFI-129 routes (see Section 5.1.1 of
[RFC6513]). If one wants, e.g., a VPN-R C-receiver to be able to receive
extranet C-flows from C-sources in VPN-S, but one does not want any VPN-R
system to be able to send unicast traffic to those C-sources, then the
UMH-eligible routes exported from VPN-S and imported by VPN-R may be SAFI-129
routes. The SAFI-129 routes areused only for UMH determination, but not
f
