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

From: "Bitar, Nabil N" <[email-masked]>
Date: Wed, 22 Oct 2014 07:42:58 -0400

Sue,
Sorry I missed this. Just for the record, I was fine with Jeff's response, and he accepted most of the suggestions as he noted. The only thing is that I think the reference related to route target should be RFC 4360 section 4 as suggested below. 
 
Thanks,
Nabil
________________________________________
From: Susan Hares [[email-masked]]
Sent: Tuesday, September 23, 2014 4:52 PM
To: 'Jeff Haas'; Bitar, Nabil N
Cc: [email-masked]; [email-masked]; [email-masked]; 'Jonathan Hardwick'; [email-masked]; 'Mach Chen'
Subject: RE: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00

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]<mailto:[email-masked]>> wrote:
Minor Issues:
Following are suggested edits.

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.

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

Accepted.

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

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

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.

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

All accepted.

Nits:
None noticed.

Thanks,
Nabil

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Oct 2014 13:51:23 -0400

Jeff: 

Would you respond to Nabil to close the loop?  You also have the Shepherd's
review.  Let's get one final draft so I can ship this to the IESG early next
week. 

Sue 

-----Original Message-----
From: Bitar, Nabil N [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2014 7:43 AM
To: Susan Hares; 'Jeff Haas'
Cc: [email-masked]; [email-masked]; [email-masked]; 'Jonathan
Hardwick'; [email-masked]; 'Mach Chen'
Subject: RE: [RTG-DIR] [RTG-DIR} RtgDir review:
draft-ietf-idr-flowspec-redirect-rt-bis-00

Sue,
Sorry I missed this. Just for the record, I was fine with Jeff's response,
and he accepted most of the suggestions as he noted. The only thing is that
I think the reference related to route target should be RFC 4360 section 4
as suggested below. 
 
Thanks,
Nabil
________________________________________
From: Susan Hares [[email-masked]]
Sent: Tuesday, September 23, 2014 4:52 PM
To: 'Jeff Haas'; Bitar, Nabil N
Cc: [email-masked]; [email-masked]; [email-masked]; 'Jonathan
Hardwick'; [email-masked]; 'Mach Chen'
Subject: RE: [RTG-DIR] [RTG-DIR} RtgDir review:
draft-ietf-idr-flowspec-redirect-rt-bis-00

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]<mailto:[email-masked]>> wrote:
Minor Issues:
Following are suggested edits.

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>

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?

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

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: "Susan Hares" <[email-masked]>
Date: Wed, 22 Oct 2014 16:43:56 -0400

Jeff and Nabil: 

RFC4360 section 3.1 and 3.2, and RFC 5668 provide the bit pattern layouts
that usually help people code.  I would recommend we include these in the
draft rather than just RFC4360.  Given that inclusion, does including
RFC4360 section 4 provide extra benefit?  My answer is that this inclusion
as

"RFC4360, section 3.1, 3.2, and 4 plus RFC 5668 section 2"  meet with both
of your approvals? 

That while the original text of: 

(See [RFC4360], Secs. 3.1, 3.2 and [RFC5668], Sec. 2.)

Provides enough context, the addition of section 4 provides good background.
Is this an agreeable compromise?  If so, I would like Jeff to revise the
document (along with Mach's shepherd comments).  

 Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Bitar, Nabil N
Sent: Wednesday, October 22, 2014 7:43 AM
To: Susan Hares; 'Jeff Haas'
Cc: [email-masked]; 'Mach Chen'; [email-masked]; [email-masked];
'Jonathan Hardwick'; [email-masked]
Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review:
draft-ietf-idr-flowspec-redirect-rt-bis-00

Sue,
 
Thanks,
Nabil

Jeff and Nabil:

Sue

Nabil,

Thanks for your review!

-- Jeff

Abstract:

Done.

- Page 3, last sentence

Suggested new text:

Accepted.

Suggested new text:

Accepted.

<Keep table here>

Suggested new text:

- 0x81

- 0x82

All accepted.

Nits:
None noticed.

Thanks,
Nabil

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Fri, 24 Oct 2014 08:13:39 -0400

Sue,
I am good with that. 

Thanks,
Nabil
________________________________________
From: rtg-dir [[email-masked]] On Behalf Of Susan Hares [[email-masked]]
Sent: Wednesday, October 22, 2014 4:43 PM
To: Bitar, Nabil N; 'Jeff Haas'
Cc: [email-masked]; 'Mach Chen'; [email-masked]; [email-masked]; 'Jonathan Hardwick'; [email-masked]
Subject: Re: [RTG-DIR] [RTG-DIR} RtgDir review: draft-ietf-idr-flowspec-redirect-rt-bis-00

Jeff and Nabil:

 Sue

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Bitar, Nabil N
Sent: Wednesday, October 22, 2014 7:43 AM
To: Susan Hares; 'Jeff Haas'
Cc: [email-masked]; 'Mach Chen'; [email-masked]; [email-masked];

Sue,

Thanks,
Nabil

Jeff and Nabil:

Sue

Nabil,

Thanks for your review!

-- Jeff

Abstract:

Done.

- Page 3, last sentence

Suggested new text:

Accepted.

Suggested new text:

Accepted.

<Keep table here>

Suggested new text:

- 0x81

- 0x82

All accepted.

Nits:
None noticed.

Thanks,
Nabil

---

From: Jeff Haas <[email-masked]>
Date: Fri, 24 Oct 2014 11:55:42 -0400

> I am good with that. 

The following edit will be present in the next rev of the draft:

@@ -155,7 +155,7 @@
     <t>
         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 <xref target="RFC4360"/>, Secs. 3.1, 3.2 and 
+    (Type).  (See <xref target="RFC4360"/>, Secs. 3.1, 3.2, and 4 plus
     <xref target="RFC5668"/>, Sec. 2.) The low order octet (Sub-Type) of the
         Redirect Extended Community remains 0x08, contrasted to 0x02 for Route
         Targets.

I am processing Mach's changes now and will publish -02 after.

-- Jeff