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

["Susan Hares" <[e-mail]>]

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:[e-mail]] On Behalf Of Eric C Rosen
Sent: Friday, December 18, 2015 9:30 AM
To: Benoit Claise; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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.

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.

 

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.    

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.



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.

I can add some text about this to section 4.4.2.  

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.


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



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.