Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen <[e-mail]>]

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".