Early Review of draft-ietf-idr-flowspec-redirect-rt-bis-00
review-ietf-idr-flowspec-redirect-rt-bis-00-rtgdir-early-bitar-2014-09-08-00

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:




 




<Keep table here> 




 




- 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