Hi, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-flowspec-redirect-rt-bis-00.txt Reviewer: Nabil Bitar Review Date: 09/07/2014 Draft had passed WG LC Intended Status: Standards Track Summary: This document addresses an issue in the definition of the redirect extended community in RFC 5575. I have somme comments pertaining to the clarity of this document that I think they should be resolved before publication. Major Issues: No major issues found. Minor Issues: Following are suggested edits. Abstract: Change:  originally documented in RFC 5575  à  originally documented in RFC 5575 (Dissemination of Flow Specification Rules) - Page 3, last sentence a common interpretation of the Redirect Extended Community’s "6-byte Route Target" has been to look for any matching Route Target sharing the same Value portion of its Extended Community. Thus, multiple Route Targets provisioned in a router’s VRFs might match even though the format was different.   Suggested new text: a common interpretation of the redirect extended community’s "6-byte route target" has been to look, at a receiving router, for a route target value that matches the route target value in the received redirect extended community, and import the advertised route to the corresponding VRF instance subject to the rules defined in RFC 5575 [RFC 5575]. However, because the route target format in the redirect extended community is not clearly defined, the wrong match may occur.   - Page 4, second paragraph:   This "Value wildcard" behavior does not matched deployed implementations of BGP Flowspec.   Suggested new text: This "value wildcard" matching behavior, that does not take into account the format of the route target defined for a local VRF and may result in the wrong matching decision, does not match deployed implementations of BGP flowspec. Deployed implementations of BGP flowspec solves this problem by defining different redirect extended communities that are specific to the format of the route target value. This document defines the following redirect extended communities:     - Page 4, first sentence under table:   It should be noted that the low-order nybble of the Redirect’s type field corresponds to the Route Target Extended Community format field (Type). (See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. 2.) The low order octet (Sub-Type) of the Redirect Extended Community remains 0x08, contrasted to 0x02 for Route Targets.   Question:   Why is the reference to RFC 4360 section 3.1 and 3.2, and RFC 5668 section 2? See to be the wrong references. Did you mean to refer to RFC 4360 section 4?   Suggested new text: It should be noted that the low-order nybble of the High-order octet of the redirect extended community yype field in Table 1 corresponds to that in the high-order octet of the route target extended community type field. The low order octet (sub-type) of the redirect extended Community remains 0x08, contrasted to 0x02 for route targets (see [RFC4360] section 4).   - Note:   I suggest that you add text on matching the newly defined redirect extended communities to route targets defined for VRF’s to update what is in RFC 5575.     Section 2 IANA Considerations (minor comments):   - 0x81 "Generic Transitive Experimental Extended Community Part 2 Sub-Types" Registry                                      -------------------   Change: Experimental à Experimental Use   - 0x82 "Generic Transitive Experimental Extended Community Part 3 Sub-Types"                                      -------------------   Change: Experimental à Experimental Use   - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED COMMUNITY PART 2 SUB-TYPES registry. It should be seeded with the following Sub-Type   Change: Experimental à Experimental Use     - IANA is requested to create the GENERIC TRANSITIVE EXPERIMENTAL EXTENDED COMMUNITY PART 3 SUB-TYPES registry. It should be seeded with the following Sub-Type     Change: Experimental à Experimental Use     Nits:   None noticed. Thanks, Nabil