Subject: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00

From: "Bitar, Nabil N" <[email-masked]>
Date: Mon, 8 Sep 2014 10:22:50 -0400

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

---

From: Jeff Haas <[email-masked]>
Date: Fri, 12 Sep 2014 14:09:03 -0400

Nabil,

Thanks for your review!

As seen below, I have accepted the majority of your changes but have yet to issue an updated draft.  There is one topic requiring some further discussion.  Once we've resolved that, I'll issue an updated I-D.

-- Jeff

On Sep 8, 2014, at 10:22 AM, Bitar, Nabil N <[email-masked]> wrote:
> Change:  originally documented in RFC 5575 à originally documented in RFC 5575 (Dissemination of Flow Specification Rules)

Done.

> 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 recei…

Accepted.

> 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 deploye…

Accepted.

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

The reference is basically to draw attention to the structural history for why this was coded the way it was.  The above references demonstrate where that structure is defined.

> 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-typ…

See above.  If you'd like to further clarify, let's talk about it in the above context.

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

I am unclear what you're asking here.  If the idea is that there should be text in this draft saying "route-targets exist and if they match this RT in the flowspec redirect, install it in the relevant VRF", I'd rather defer to the underlying base behavior in 5575.

> "Generic Transitive Experimental Extended Community Part 2 Sub-Types" Registry

All accepted.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Sep 2014 16:52:42 -0400

Jeff and Nabil:

I’ve not seen any further conversation on this topic?  Is the resolution
pending offline? Or can we complete this topic?  I would like to push this
draft through the process. 

Please note Mach Chen has agreed to be the shepherd on this draft, but it’s
his first IDR shepherding so you WG co-chair is helping keep the ball
rolling.  

Sue 

From: rtg-dir [mailto:[email-masked]] On Behalf Of Jeff Haas
Sent: Friday, September 12, 2014 2:09 PM
To: Bitar, Nabil N
Cc: [email-masked]; [email-masked]; [email-masked]; Jonathan
Hardwick; [email-masked]; Susan Hares
Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review:
draft-ietf-idr-flowspec-redirect-rt-bis-00

Nabil,

Thanks for your review!

As seen below, I have accepted the majority of your changes but have yet to
issue an updated draft.  There is one topic requiring some further
discussion.  Once we've resolved that, I'll issue an updated I-D.

-- Jeff

On Sep 8, 2014, at 10:22 AM, Bitar, Nabil N <[email-masked]>
wrote:

Minor Issues:

Abstract:

Change:  originally documented in RFC 5575 à originally documented in RFC
5575 (Dissemination of Flow Specification Rules)

Done.

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

Accepted.

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:

Accepted.

<Keep table here>

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?

The reference is basically to draw attention to the structural history for
why this was coded the way it was.  The above references demonstrate where
that structure is defined.

Suggested new text:

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

See above.  If you'd like to further clarify, let's talk about it in the
above context.

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

I am unclear what you're asking here.  If the idea is that there should be
text in this draft saying "route-targets exist and if they match this RT in
the flowspec redirect, install it in the relevant VRF", I'd rather defer to
the underlying base behavior in 5575.

- 0x81

"Generic Transitive Experimental Extended Community Part 2 Sub-Types"
Registry

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

- 0x82

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

- 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

 

- 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

All accepted.

Nits: 

None noticed.

Thanks,

Nabil

---

From: Jeff Haas <[email-masked]>
Date: Tue, 23 Sep 2014 23:02:10 -0400

Sue,

I'm still waiting to hear back from Nabil about the one open point.

-- Jeff

On Sep 23, 2014, at 4:52 PM, Susan Hares <[email-masked]> wrote:

> Jeff and Nabil:
>  
> I’ve not seen any further conversation on this topic?  Is the resolution pending offline? Or can we complete this topic?  I would like to push this draft through the process.
>  
> Please note Mach Chen has agreed to be the shepherd on this draft, but it’s his first IDR shepherding so you WG co-chair is helping keep the ball rolling. 
>  
> Sue
>  
> Cc: [email-masked]; [email-masked]; [email-masked]; Jonathan Hardwick; [email-masked]; Susan Hares
> Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00
>  
> Nabil,
>  
> Thanks for your review!
>