I responded to Sue's review, but noticed that the response did not go to
the BESS mailing list. So I am sending my response again; apologies to
those who are getting it twice.
On 12/17/2015 7:47 AM, Susan Hares wrote:
Eric, Rahul, Yiqun, and Thomas:
I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These
comments were written with the intent of improving the operational
aspects of the
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews
during the IESG review. Document editors and WG chairs should treat
these comments
just like any other last call comments.
Please let me know if any of these comments are unclear. This is
interesting BESS work, and a clear deployable specification will help
with multicast traffic (video and other traffic).
Sue Hares
======
Status: Not ready, three major concerns and two editorial nits:
Major concerns:
1)Specification of the Extranet Source Extended Community and Extra
Source extended Community
Please provide the type of detail as show in RFC 4360 sections 3.1,
3.2, and 3.3.
It would not be correct to do so. As you may recall, RFC7153
reorganized the Extended Community registries, and Section 4 of RFC7153
provides instructions on how to request Extended Community codepoints
from IANA. In fact, one of the main purposes of RFC7153 was to
eliminate the need to provide IANA with the sort of detail that is
indicated in RFC4360. I believe that the specification of the two ECs
(and the request for codepoints for them) is in accord with RFC7153 and
does not need revision.
2)Why is there no Deployment considerations section?
There is no requirement for a Deployment Considerations section, so
absence of one cannot be grounds for a DISCUSS. I will interpret this
comment as meaning that there is insufficient discussion of deployment
issues. However, I find the comment puzzling, as so much of the draft
is about proper provisioning of the Route Targets, and Route
Distinguishers. There is also quite a bit of discussion about corner
cases, such as (a) the problem that may arise if a source host
originates both extranet and non-extranet sources, and (b) the problem
that may arise if a single address prefix is the best match for both an
extranet source and a non-extranet source.
In fact, you say yourself:
The whole draft is a set of rules for handling policy, BGP A-D routes,
tunnel set-up, and PIM Join/leaves in the case of an intra net.
Unless these rules are followed exactly, traffic may flow into a VPN
it is not suppose to.
So I really don't understand what you think is missing.
If the customer and the SP must coordinate on setting up filters, the
procedure is outside the document.
Yes, the interaction between the service provider and its customers is
outside the scope of this document.
An error in any of these set-ups is considered a “security violation”.
Not quite; any error in these set-ups could result in a security
violation, i.e., in delivery of data to hosts that aren't supposed to
get it.
In this set-up, one has to ask “is there another choice” to this whole
design
Certainly the WG has had plenty of time to come up with up with a better
alternative.
there should be a deployment section indicating how to manage the
RTs, RDs, and policy set-up.
I do not understand what you think is missing. This is covered quite
extensively in sections 1.3, 4, and 5.
Perhaps experience with the Intra-As has shown deployment tips that
would make this less fragile. If so, it would be good to include an
operations consideration section.
I do not think there is any requirement to have "deployment tips" in
this document, nor is there any requirement to have an "operations
considerations" section. However, since so much of the document is
devoted to the issue of how to properly provision the RTs and RDs, I
don't quite understand what you think is not covered.
If a new class of tools provides monitoring or provisioning,
mentioning these would be useful. If yang modules are being
developed, that would be useful.
It is not within the scope of this document to "mention" monitoring or
provisioning tools. Yang models are also outside the scope of this
document.
Places that indicate issues with violated constraint:
p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), ,
I am not entirely sure what you are asking.
As discussed in Section 2, the big problem in MVPN extranet is that an
egress PE may receive two distinct multicast flows that happen to have
the same IP source and IP group address, say (S,G). The procedures
and policies specified in the draft prevent two such flows from
traveling across the backbone on the same tunnel. However, the detailed
examples in sections 2.1 and 2.2 show how a given egress VRF can end up
listening to two tunnels, each of which is carrying an (S,G) flow. In
this case, only one of the tunnels is carrying the (S,G) flow that needs
to be delivered to the VRF, but the other tunnel is carrying other flows
that need to be delivered to the VRF.
The problem is how to prevent the "wrong" (S,G) flow from being
delivered to a given VRF. Section 2.3 outlines two methods for
preventing this:
- Since the VRF "knows" the tunnel from which to expect the (S,G) flow,
it can discard (S,G) packets coming from the other tunnel. However, not
all deployed hardware platforms are able to do this at speed. Hence the
other alternative:
- Don't put more than one flow on a tunnel; then if (S,G) is flowing on
two tunnels, a given egress VRF will only be listening to one of them.
That eliminates the problematic situation in which "the other tunnel is
carrying other flows that need to be delivered to the VRF". The actual
constraint is a bit more complicated than 'don't put more than one flow
on a tunnel', but this is detailed in Section 2.3.
I think this is all explained in the draft. Are you saying that the
explanation above is incomprehensible, or are you saying that the draft
just doesn't make it clear and needs some additional text? Or are you
saying something else?
p. 25 last paragraph (violation of constraints will cause things to
not work. However, only policy can control),
Again, not sure what you are asking. This page specifies a set of
constraints on the way RTs are assigned. It points out that these
constraints are presupposed by the procedures that are later specified
for determining whether a given flow is expected to arrive from a given
tunnel. It is explained elsewhere in the document that accepting a flow
from other than the expected tunnel can result in misdelivery of data.
What else needs to be added?
p. 27 4.2.2 (1^st paragraph, Route Reflector must not change),
That's section 4.4.2; the topic is the propagation of routes that carry
the Extranet Source EC.
Recall that a CE puts the Extranet Source EC on an IP route to indicate
that the route represents an extranet source. The PE then translates
the IP route to a VPN-IP route, and attaches a specific set of RTs to
the VPN-IP route. The draft requires that the Extranet Source EC also
be carried by the VPN-IP route, and that it not get stripped off while
the VPN-IP route is being propagated. This rule is needed in order to
support the scenario in which a VPN contains an "Option A"
interconnect. At the Option A interconnect, the VPN-IP route gets
translated back to an IP route, and the RTs are stripped off before the
IP route is propagated. If the Extranet Source EC has also been
stripped off, there is no way for the router at the other end of the
Option A interconnect to know that the route represents an extranet
source. Thus the technique of using the Extranet Source EC to
dynamically signal that a particular route represents an extranet source
will not work correctly across an Option A interconnect unless the rules
of section 4.4.2 are followed.
I can add some text about this to section 4.4.2.
p. 31 (5.1, first paragraph),
Section 5.1 specifies a set of constraints on the assignment of RTs, and
explains the need for them. I'm not sure what more you think is necessary.
3)Is security section really a security section? It seems more like
“do this policy” or this will fail. It should get a stronger review
from the security directorate
The Security Considerations section mentions those things that are
specific to MVPN Extranet and that need to be done properly in order to
prevent misdelivery of data. That seems like an appropriate security
section for this document. General issues of
privacy/integrity/authentication are not specific to MVPN Extranet, and
so are not mentioned here.
Editorial suggestions:
Summary: In general the authors provide dense English text to describe
this rules. In general the English text contains valid complex
sentences. However, a few things should be suggested:
1)PTA – define it in a definition section or spell out the abbreviation
This acronym is expanded at first occurrence, but I will be happy to add
it to the Terminology section as well.
4)P. 36 second paragraph. The reason for the “MUST” in 1^st full
paragraph is a bit vague. It seems logical, but the reasoning is just
vague in the text.
Are you referring to the following:
"the VPN-R VRF MUST also originate one or more additional
Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra-
AS I-PMSI A-D route for each Incoming Extranet RT with which it has
been configured"
*
*At the beginning of section 6.2, it says:
"if a VPN-S VRF has extranet multicast C-sources, and a
VPN-R VRF has extranet multicast C-receivers allowed by policy to
receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins
the MI-PMSI that VPN-S uses for its non-extranet traffic."
The former paragraph describes the mechanism that VPN-R uses to join the
MI-PMSI into which VPN-S transmits. I can add a sentence to the
paragraph on page 36 saying "This is the method that VPN-R uses to join
the MI-PMSIs that may contain extranet flows that are of interest to it".
7)Page 53 – section 7.4.5 paragraph 3 “VRF route Import EC” – please
spell out first usage and give abbreviation (VRF Route Import Extended
Community (EC).
I see only two occurrences of "EC" in the draft, so I'll just replace
them with "Extended Community".
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
