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

From: "Benoit Claise" <[email-masked]>
Date: Thu, 17 Dec 2015 05:30:49 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-bess-mvpn-extranet-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As mentioned in Sue Hares' OPS DIR, 3 major concerns. The last one is
actually for the security ADs.

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.  

2)      Why is there no Deployment considerations section? 

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.

If the customer and the SP must coordinate on setting up filters, the
procedure is outside the document.

An error in any of these set-ups is considered a “security violation”. 

Milo Medin stated “with enough trust” a rock can fly to the moon. 
However, the NASA flights were fragile and risky.  In the journey to the
moon, there was no other choice.  Instrumentation has 4-5 backups.

In this set-up, one has to ask “is there another choice” to this whole
design that seem fragile addition of extranets to an intra-AS multicast
design.  If the design is not fragile, then there should be a deployment
section indicating how to manage the RTs, RDs, and policy set-up. 
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.

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.

Places that indicate issues with violated constraint:

p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25
last paragraph (violation of constraints will cause things to not work. 
However, only policy can control), p. 27 4.2.2 (1st paragraph, Route
Reflector must not change), p. 31 (5.1, first paragraph),

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

2)      Phrases like  “the RT RT-R” become overly dense.  Use “Route
Target RT-R”.

3)      Breaking up section 6.2.1 – with subjection and subtitles would
make it more readable,

4)      P. 36 second paragraph.  The reason for the “MUST” in 1st full
paragraph is a bit vague.  It seems logical, but the reasoning is just
vague in the text.

5)      paragraph 2 in page 47 (section 7.3.1) is awkward, please reword.

6)      Paragraph 5 in page 47 (section 7.3.1) – does not explain why the
condition should hold.  The authors have done this in eac other case, so
it seems inconsistent.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Dec 2015 13:54:14 +0000

> “do this policy” or this will fail.  It should get a stronger review from

I've not posted a ballot for this one as my question is more
"What does P really stand for in this kind of VPN?" and I don't
really get what here is new that requires a PS. So any security
discuss would likely be met by "not new, can't change" and is
therefore perhaps not the best use of our time. It'd be better
if we could get some folks to try to re-instate the P == Private
in VPN. (But that is admittedly very hard if one really has to
do multicast.)

S.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Dec 2015 09:00:40 -0500

Stephen: 

They are adding 2 BGP Extended communities.  They are modifying rules for distribution of BGP routes and PIM trees in the case of MPLS VPNs supporting multicast.  The thing that worries me is they are stating that "breaking any of the policy rules" is a security consideration.  However, as far as I can tell the specification lacks an indication of how to trace or audit such rules.  

P as to "Private" VPNS is simply an indication of overlay VPNS used for a set of customers.  Just one variant of routing technology specified, IMHO. 

Sue 

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, December 17, 2015 8:54 AM
To: Benoit Claise; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

On 17/12/15 13:30, Benoit Claise wrote:
> “do this policy” or this will fail.  It should get a stronger review 
> from the security directorate

I've not posted a ballot for this one as my question is more "What does P really stand for in this kind of VPN?" and I don't really get what here is new that requires a PS. So any security discuss would likely be met by "not new, can't change" and is therefore perhaps not the best use of our time. It'd be better if we could get some folks to try to re-instate the P == Private in VPN. (But that is admittedly very hard if one really has to do multicast.)

S.

_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 18 Dec 2015 09:30:01 -0500

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
>
> ======
>
> 1)Specification of the Extranet Source Extended Community and Extra 
> 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:
> 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.
> 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.

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

> 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 

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

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Dec 2015 14:01:43 -0500

Eric: 

Detailed response to your comments below are in red for the current comments (except in the template for Major point #1). For the 3 Major comments, let me provide you a quick guide to resolving these points so you can get past the DISCUSS quickly. 

1)      For BGP Extended community text – I have provide templates for sections that will resolve this point.  If you send me text back, I will confirm the changes ASAP,

2)      For Deployment section – As an OPS-DIR/NM reviewer, one my reviewing points is whether the operational issues in deployments are: a) fully specified, and b) summarized so operational people can get the high-level picture.   My major concern is that “b” does not exist, and you feel it is not a requirement.  It is this point we are sticking on.  

To resolve (b) sticking: Please just try summarizing as you would in an academic abstract the deployment issues.  3+ paragraphs should solve this point.  Given you have written 60 pages and deploy it, I suspect you can quickly write a high-level overview.   If you wish to send me a deployment considerations overview, then I will be glad to read it.  

My comments on the text were also to improve readability of the text so I could tell if (a) “fully” specified was there. However, I believe that 90%-95% of all cases are specified.  While I tried to point out places where it was not clear, these are editorial comments.  You do not have to resolve these to remove the Major issue #2.   

3)      Security considerations – This was handed off to Security Directorate, Kathleen and Stephen.  If this group of security people are happy, then Benoit will clear this point as part of the DISCUSS.  

Editorial points – are just that.  You can take them or leave them. Thank you for considering these editorial issue. 

Sue 

From: BESS [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Friday, December 18, 2015 9:30 AM
To: Benoit Claise; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

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.

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 

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

======

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.

I recall and I disagree with your assumptions that the IANA specification is equivalent to the routing specification.  The abstract of RFC7153 states: 

   This is done in order to remove interdependencies among the registries, thus
   making it easier for IANA to determine which code points are available
   for assignment in which registries.  This document also clarifies the
   information that must be provided to IANA when requesting an
   allocation from one or more of these registries.  These changes are
   compatible with the existing allocations and thus do not affect
   protocol implementations.  The changes will, however, impact the
   "IANA Considerations" sections of future protocol specifications.
   This document updates RFC 4360 <https://tools.ietf.org/html/rfc4360>  and RFC 5701 <https://tools.ietf.org/html/rfc5701> .

Your stating how the “IANA” portion should be requested is not appropriate for this section.  What you are referring to is: 

   When a codepoint is needed for a new Extended Community, the
   requester should first determine whether an existing Type can be
   used.  If so, IANA should be asked to allocate a codepoint from the
   corresponding Sub-Type registry, if there is one.

You have asked for an Opaque Transitive Extended Community. 

What I cannot tell from your description what fields exist or the values in these two communities.  If I,  who have read many of these drafts,  cannot make sense of your text it is a fallacy to believe the implementer will have a clear understanding. 

You state in 4.4.1 

   To facilitate this, we define a new Transitive Opaque Extended
   Community, the "Extranet Source" Extended Community.  When a CE
   router advertises (via BGP) a route to a PE router, and the AFI/SAFI
   of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source
   Extended Community MAY be attached to the route.  The value field of
   the Extended Community MUST be set to zero. 
 
This mixes the definition within the  text rather than laying it cleanly.  
 
To be proactive, here is a set of text to fix my concern with the text. 
 
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.    
 
This value field MUST be set  to zero upon origination, MUST be ignored upon reception, and MUST  be passed unchanged by intermediate routers.
 
  [Sue Should the text in red be added to this community usage?  If so, it would be helpful to symmetrical.  If not, please indicate where you allow it to be reset in the text.  ]
 
  Restrictions on origination:  ?? 
  Restrictions on Adding/deleting this community:    
 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.  
 
   Fields: 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 origination:  ?? 
  Restrictions on Adding/deleting this community:  ??  

2)      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.    

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. 

Sue-2: This is an OPS-DIR review of the document.  One of the categories we check is if there is sufficient information for operational deployment in a summary form and in understandable detail.  

Your details presents problems in section 2, hypothetical cases (section 3-7), and expects a general information to be intuited out of the draft.   Any variance from the prescribed rules is a “security consideration”.  There is no debugging aid to make sure these rules are followed.   Surely, since your company plans to deploy this, must have a set of deployment aids for debugging or some operational guidance for your customer.  

My suggestion is to put in a 2-4 paragraphs in a section giving some advice on how to deploy, how to debug (RT, RD, policy rules, filters, erroneous filters), tips on how to go from Intra-AS M-VPN to extra.    It is a high-level “so-what” that operators may as a level setting for the Extra-Net case.  

 Extra words in defense from you on this case: 

·         Sue: If the customer and the SP must coordinate on setting up filters, the procedure is outside the document. 

·         Eric: Yes, the interaction between the service provider and its customers is outside the scope of this document.

·         
Sue: An error in any of these set-ups is considered a “security violation”.  

·         Eric: 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.

·         Sue-2: Yes. Errors do result in security violations.  This says this protocol is more dangerous that other routing protocol signaling.  So, how are you going to help the user.  Remember – this is a OPS-DIR/NM review. 

Sue: In this set-up, one has to ask “is there another choice” to this whole design.

Eric: Certainly the WG has had plenty of time to come up with up with a better alternative. 

Sue-2: The question is did you have other design choices that could reduce the management overhead and the potential for error? 

Sue:  there should be a deployment section indicating how to manage the RTs, RDs, and policy set-up. 

Eric: I do not understand what you think is missing.  This is covered quite extensively in sections 1.3, 4, and 5.
Sue-2: See comments above. 

Sue: 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.

Eric:  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.

Sue-2:  See comments above on the need for a deployment summary giving these tips.  OPS-DIR/NM reviews look to see if the operations people can use it.  IMO, you need a summary section to make this useable.  My suggestions is 3 paragraphs of tips would be sufficient.  After 60 pages of text, surely you can summarize in 3 paragraphs as you would in any academic paper’s abstract.  

Sue:  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. 

Eric:  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.

Sue-2:  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? If you need tools, simply say they are needed. If you do not need tools, simply state that.  To call it out of scope for a 60 page document of rules, seems at best unwise from an OPS/NM perspective.   It would seem simply to add a paragraph in the deployments summary to address this point. 

Out of context: 

Sue-1: The reason why you needed debugging is that several places that indicate issues with violated constraint:  p. 11, p12, 19 (2.3.2 – a priori knowledge, inability to detect), 

Eric: I am not entirely sure what you are asking.

Sue-2: I am indicated 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”.   The deployment section summary should tell those deploying this protocol how to detected and debug issues with “constraint violations”. 

Sue-2: This whole section gives you a set of examples of text that could cause conflicting operational issues as example on why you need a OPS-DIR/NM deployment summary: 

Sue: 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.

p. 25 last paragraph (violation of constraints will cause things to not work.  However, only policy can control),

p. 27 4.2.2 (1st paragraph, Route Reflector must not change), 

Eric: 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 mis-delivery of data.  What else needs to be added?

Sue: p. 31 (5.1, first paragraph): This provides rules on the contraints 

Eric: 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.

Sue-2:  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. 

===============

Eric: 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?

Sue-2: For the major concern, I am saying that this system has complexity that goes beyond many other systems. As such, it needs a deployment summary section to guide the OPS/NM.  I am pointing out the complexity and varied assumptions so you can step outside of yourself, and look at it from an operators viewpoint. 

My concern is that you sweep all of the errors that an operator in deployment into the one pile of “if you make a mistake, then you could send traffic where it should not go;  these mistakes would cause a security violation”.  I agree policy mistakes cause security violations, but saying 50+ rules must be adhered to or you get security. 

For an editorial comment (and not a Major comment/DISCUSS), I find the draft to be difficult to read.  It seems to be a draft caught in the middle of a compromise with varying styles of writing.   A clear revision of the draft with pictures and examples would make it easier to read.  With great effort, one can work through all the text. 

========

Sue 2: These were pointing out the need for deployment section.  However, any editorial aid would be helpful.

Sue: p. 27 4.2.2 (1st paragraph, Route Reflector must not change), 

Eric:  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.

Sue-02: That would be helpful. 

=========

Major point 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.

Sue-02: My goal as a OPS-DIR review is to flag anything I think should be reviewed by other experts.  I believe Kathleen has already taken care of this issue.  If Kathleen, Stephen and SEC-DIR is happy, then any of these comments are editorial in nature. 

Eric: 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.

Sue-2:  I agree the key issue you are raising is that misconfiguration of the 25+ rules can cause misdelivery of data.  My point is that any routing system that depends on 25+ rules to get right is a fragile system.  

Your document does provide defaults.  It would be good to highlight how defaults can ease operational issues in the deployment, and in the security section. 

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)     Sue: PTA – define it in a definition section or spell out the abbreviation

Eric: This acronym is expanded at first occurrence, but I will be happy to add it to the Terminology section as well.

Sue-2: Thank you. 

4)      P. 36 second paragraph.  The reason for the “MUST” in 1st full paragraph is a bit vague.  It seems logical, but the reasoning is just vague in the text.

At the beginning of section 6.2, it says:

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

Sue-2: This is fine.   Given the number of rules section pointers in the above text are useful. 

Sue: 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).  

Eric: I see only two occurrences of "EC" in the draft, so I'll just replace them with "Extended Community".

Sue-2: yes – this is my point.  I think this minor change will aid readability.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 21 Dec 2015 14:58:36 -0500

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

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 22 Dec 2015 09:52:45 -0500

Draft-ietf-bess-mvpn-extranet-05 has been posted.

This revision contains some edits to the sections on the Extended 
Communities, and some other editorial changes, stemming from the ops-dir 
review.

I did not follow the suggestion of the ops-dir review to add an 
"Operator Tips and Tricks" section, as that would be outside the scope 
of the document, and there is no IETF requirement to include such a section.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 22 Dec 2015 12:51:54 -0500

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: 

===================

   (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).

   Restrictions:  Its value field MUST be set to zero upon origination, MUST be ignored upon reception, and MUST be

  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-masked]] 
Sent: Monday, December 21, 2015 2:59 PM
To: Susan Hares; 'Benoit Claise'; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.

deployment section to guide operations on deployment tools, tips, and constraints.

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.

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.

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

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 22 Dec 2015 14:08:15 -0500

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.

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

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Dec 2015 10:13:38 -0500

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 

----------------------------------------------------------------

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.  

 

From: BESS [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Tuesday, December 22, 2015 2:08 PM
To: Susan Hares; 'Benoit Claise'; 'The IESG'
Cc: [email-masked]; 'John G. Scudder'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

Eric: 

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.  

 

Perhaps.

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.