+gen-art review who noted similar issues in the registration policy
On Apr 10, 2015, at 12:37 PM, Pearl Liang via RT <[email protected]>
wrote:
> Hi Sue, and Jeff,
>
> Thank you Sue for clarifying the timeline and the IANA actions. Your
> instructions are very
> clear. Just a few nits/question.
>
> - Regarding the Form for new created registries:
>
> Form: Sub-type Value, Name, Reference, Registration Type
>
> Can you clarify what types of information will go to the element
> "Registration Type"
> in the BGP Extended Communities registry?
I believe Sue had intended this to match the form of the existing "Generic
Transitive Experimental Use Extended Community Sub-Types" registry. This
includes sub-type value and name as fields with reference to the document and
date. Is that right, Sue?
>
> - This is likely for Jeff. I noticed now that the two new registrations for
> Part 2
> Sub-Types and Part 3 Sub-Types have different names in the IC section:
>
> /snip/
> IANA is requested to create the "Generic Transitive Experimental Use
> Extended Community Part 2 Sub-Types" registry. It should be seeded
> with the following Sub-Type:
>
> 0x08 - Flow spec redirect IPv4 format.
>
> IANA is requested to create the "Generic Transitive Experimental Use
> Extended Community Part 3 Sub-Types" registry. It should be seeded
> with the following Sub-Type:
>
> 0x08 - Flow spec redirect AS-4byte format.
> /snip/
I think the text was unclear. The intention is to create two new registries in
the form of the "Generic Transitive Experimental Use Extended Community
Sub-Type". The new registries are distinct in that the first octet value (the
type) is 0x81 and 0x82 for Part 2 and Part 3 respectively.
Within each of those registries, there is a single entry registered,as per
above.
Please see the attachment at the end of this mail for new proposed IANA
Considerations text that I believe conveys this intent. It contains all edits
to date.
>
> Please update the names to the one in Sue's comment if the names should
> be consistent in both sub-regisries.
>
> I'll let you work on the action items on your end. If you have questions for
> us,
> please contact us.
>
> Thanks,
> ~pl
>
>
> On Fri Apr 10 00:33:05 2015, [email protected] wrote:
>> Pearl:
>>
>> This is my understanding of what needs to change, and hopefully
>> answers all your questions. I apologize that this draft got to you
>> without the new form.
>>
>> I'll wait for an acknowledgement from Jeff that he is re-writing the
>> draft to cover these changes. Once Jeff has re-written the draft, this
>> draft will be 1 week WG LC to cover this change. Please set your
>> timer to check on this in 2 week.
>>
>> Answers to your questions:
>> O Action 1, Q1: the RFC should be [RFC5575, RFC-to-Be]
>> On Action 2, this is correct, Please update the free space in the
>> registry to indicate only 0x83 to 0x8f are free.
Agreed.
>>
>> On action 3, Q1: Please create a new entry under the following web-
>> page
>> http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-
>> communities.xhtml
>>
>> Name the web page the following:
>> "Generic Transitive Experimental Use
>> Extended Community Part 2 Sub-Types" registry.
>>
>> Form: Sub-type Value, Name, Reference, Registration Type
>>
>> Sub-Type Value Name Reference Registration-type
>> 0x00-0x07 TBD TBD
>> Standards action
>>
>> 0x08 Flow Spec redirect
>> AS-4byte format [This-RFC] Standards
>>
>> 0x09-0x40 TBD TBD Standards
>> action
>> 0x41-0xff Reserved
Sue, is there any reason to not use a similar registration range as the 0x80
range? I.e.:
0x00-0xbf - FCFS
0xc0-0xff - IETF review?
>>
>>
>> On action 3, Q4:
>> Please create a new entry under the following web-page
>> http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-
>> communities.xhtml
>>
>> Name the web page the following:
>> "Generic Transitive Experimental Use
>> Extended Community Part 3 Sub-Types" registry.
>>
>> Form: Sub-type Value, Name, Reference, Registration Type
>>
>> Example:
>> Sub-Type Value Name Reference Registration-type
>> 0x00-0x07 TBD TBD
>> Standards action
>>
>> 0x08 Flow Spec redirect
>> AS-4byte format [This-RFC] Standards
>>
>> 0x09-0x40 TBD TBD Standards
>> action
>> 0x41-0xff Reserved
>>
>>
>> Sue Hares
>>
>> -----Original Message-----
>> From: Pearl Liang via RT [mailto:[email protected]]
>> Sent: Tuesday, April 07, 2015 2:42 PM
>> Cc: [email protected];
>> [email protected]; [email protected]
>> Subject: [IANA #814082] Last Call: <draft-ietf-idr-flowspec-redirect-
>> rt-bis-03.txt> (Clarification of the Flowspec Redirect Extended
>> Community) to Proposed Standard
>>
>> (BEGIN IANA LAST CALL COMMENTS)
>>
>> IESG/Authors/WG Chairs:
>>
>> IANA has reviewed draft-ietf-idr-flowspec-redirect-rt-bis-03. Authors
>> should review the comments and/or questions below. Please report any
>> inaccuracies and respond to any questions as soon as possible.
>>
>> IANA has several questions about some of the actions requested in the
>> IANA Considerations section of this document.
>>
>> We received the following comments/questions from the IANA's reviewer:
>>
>> IANA understands that, upon approval of this document, there are four
>> actions which IANA is required to complete.
>>
>> First, in the Generic Transitive Experimental Use Extended Community
>> Sub-Types subregistry of the Border Gateway Protocol (BGP) Extended
>> Communities registry located at:
>>
>> http://www.iana.org/assignments/bgp-extended-communities/
>>
>> the existing registration for Type Value 0x08 will have its name
>> updated from:
>>
>> Flow spec redirect
>>
>> to:
>>
>> Flow spec redirect AS-2byte format
>>
>> and have the reference changed to [ RFC-to-be ]
>>
>> QUESTION [1]: This draft indicates that it updates RFC5575 according
>> to the header information in the draft. Is the author intended to
>> remove the existing defining reference from the registry?
>>
>>
>> Second, in the BGP Transitive Extended Community Types subregistry
>> also in the Border Gateway Protocol (BGP) Extended Communities
>> registry located at:
>>
>> http://www.iana.org/assignments/bgp-extended-communities/
>>
>> two new registrations will be added as follows:
>>
>> Type Value: 0x81
>> Name: Generic Transitive Experimental Use Extended Community Part 2
>> (Sub-Types are defined in the "Generic Transitive Experimental
>> Extended Community Part 2 Sub-Types" Registry)
>> Reference: [ RFC-to-be ]
>>
>> Type Value: 0x82
>> Name: Generic Transitive Experimental Use Extended Community Part 3
>> (Sub-Types are defined in the "Generic Transitive Experimental
>> Extended Community Part 3 Sub-Types" Registry)
>> Reference: [ RFC-to-be ]
>>
>> Third, a new registry is to be created called the "Generic Transitive
>> Experimental Use Extended Community Part 2 Sub-Types" registry.
>>
>> IANA QUESTION [1] -> Where should this new registry be located? Is it
>> a néw registry on the IANA Matrix or is it a subregistry of an
>> existing registry? If it is a subregistry of an existing registry, in
>> which registry will it be contained? In the same BGP Extended
>> Communities located at http://www.iana.org/assignments/bgp-extended-
>> communities registry?
>>
>> IANA QUESTION [2] -> What rules should be used for maintenance of
>> this new registry? Please refer to RFC 5226 for guidance on how to
>> select and apply maintenance policy for a new registry.
>>
>> QUESTION: [3] What is the range for this new Part 2 Sub-Types
>> registry?
>>
>> QUESTION: [4] Is the author intended to use the same table format as
>> the existing sub-registry
>> "Generic Transitive Experimental Use Extended Community Sub-Types"
>> which has
>> the following columns: Sub-Type Value, Name, Reference, and
>> (Registration) Date?
>>
>> IANA understands that there is a single initial registration in the
>> new registry as follows:
>>
>> Type Value: 0x08
>> Name: Flow spec redirect IPv4 format
>> Reference: [ RFC-to-be ]
>>
>> Fourth, a new registry is to be created called the "Generic Transitive
>> Experimental Use Extended Community Part 3 Sub-Types" registry.
>>
>> IANA QUESTION [1] -> Where should this new registry be located? Is it
>> a néw registry on the IANA Matrix or is it a subregistry of an
>> existing registry? If it is a subregistry of an existing registry, in
>> which registry will it be contained?
>>
>> IANA QUESTION [2] -> What rules should be used for maintenance of this
>> new registry? Please refer to RFC 5226 for guidance on how to select
>> and apply maintenance policy for a new registry.
>>
>> QUESTION: [3] What is the range for this new Part 3 Sub-Types
>> registry?
>>
>> QUESTION: [4] Is the author intended to use the same table format as
>> the existing sub-registry
>> "Generic Transitive Experimental Use Extended Community Sub-Types"
>> which has
>> the following columns: Sub-Type Value, Name, Reference, and
>> (Registration) Date?
>>
>> IANA understands that there is a single initial registration in the
>> new registry as follows:
>>
>> Type Value: 0x08
>> Name: FFlow spec redirect AS-4byte format
>> Reference: [ RFC-to-be ]
>>
>> IANA understands that these four actions are the only ones required to
>> be completed upon approval of this document.
>>
>> Note: The actions requested in this document will not be completed
>> until the document has been approved for publication as an RFC. This
>> message is only to confirm what actions will be performed.
>>
>> Please note that IANA cannot reserve specific values. However, early
>> allocation is available for some types of registrations. For more
>> information, please see RFC 7120.
>>
>> Thanks,
>>
>> Pearl Liang
>> ICANN
>>
>> (END IANA LAST CALL COMMENTS)
>>
>>
>> On Wed Mar 18 20:33:49 2015, [email protected] wrote:
>>>
>>> The IESG has received a request from the Inter-Domain Routing WG
>>> (idr)
>>> to
>>> consider the following document:
>>> - 'Clarification of the Flowspec Redirect Extended Community'
>>> <draft-ietf-idr-flowspec-redirect-rt-bis-03.txt> as Proposed
>>> Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to
>>> the
>>> [email protected] mailing lists by 2015-04-08. Exceptionally, comments
>>> may
>>> be
>>> sent to [email protected] instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>> This document clarifies the formatting of the the BGP Flowspec
>>> Redirect Extended Community, originally documented in RFC 5575
>>> (Dissemination of Flow Specification Rules).
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-
>>> bis/
>>>
>>> IESG discussion can be tracked via
>>> http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-
>>> bis/ballot/
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>
>
Internet Engineering Task Force J. Haas, Ed.
Internet-Draft Juniper Networks
Updates: 5575 (if approved) April 10, 2015
Intended status: Standards Track
Expires: October 12, 2015
Clarification of the Flowspec Redirect Extended Community
draft-ietf-idr-flowspec-redirect-rt-bis-04
Abstract
This document updates RFC 5575 (Dissemination of Flow Specification
Rules) to clarify the formatting of the the BGP Flowspec Redirect
Extended Community.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Haas Expires October 12, 2015 [Page 1]
Internet-Draft draft-ietf-idr-flowspec-redirect-rt-bis April 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
2.1. Update to BGP Generic Transitive Experimental Use
Extended Community Sub-Types . . . . . . . . . . . . . . 4
2.2. Generic Transitive Experimental Extended Community Part 2
Sub-Types . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Generic Transitive Experimental Extended Community Part 3
Sub-Types . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Dissemination of Flow Specification Rules [RFC5575], commonly known
as BGP Flowspec, provided for a BGP Extended Community [RFC4360] that
served to redirect traffic to a VRF routing instance that matched the
flow specification NLRI. In that RFC, the Redirect Extended
Community was documented as follows:
Haas Expires October 12, 2015 [Page 2]
Internet-Draft draft-ietf-idr-flowspec-redirect-rt-bis April 2015
: +--------+--------------------+--------------------------+
: | type | extended community | encoding |
: +--------+--------------------+--------------------------+
: | 0x8008 | redirect | 6-byte Route Target |
: +--------+--------------------+--------------------------+
:
: [...]
:
: Redirect: The redirect extended community allows the traffic to be
: redirected to a VRF routing instance that lists the specified
: route-target in its import policy. If several local instances
: match this criteria, the choice between them is a local matter
: (for example, the instance with the lowest Route Distinguisher
: value can be elected). This extended community uses the same
: encoding as the Route Target extended community [RFC4360].
: [...]
:
: 11. IANA Considerations
: [...]
:
: The following traffic filtering flow specification rules have been
: allocated by IANA from the "BGP Extended Communities Type -
: Experimental Use" registry as follows:
: [...]
:
: 0x8008 - Flow spec redirect
The IANA registry of BGP Extended Communities clearly identifies
communities of specific formats. For example, "Two-octet AS Specific
Extended Community" [RFC4360], "Four-octet AS Specific Extended
Community" [RFC5668] and "IPv4 Address Specific Extended Community"
[RFC4360]. Route Targets [RFC4360] identify this format in the high-
order (Type) octet of the Extended Community and set the value of the
low-order (Sub-Type) octet to 0x02. The Value field of the Route
Target Extended Community is intended to be interpreted in the
context of its format.
Since the Redirect Extended Community only registered a single code-
point in the IANA BGP Extended Community registry, 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 [RFC5575].
However, because the route target format in the redirect extended
community is not clearly defined, the wrong match may occur.
Haas Expires October 12, 2015 [Page 3]
Internet-Draft draft-ietf-idr-flowspec-redirect-rt-bis April 2015
This "value wildcard" matching behavior, which 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 solve 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:
+--------+--------------------+-------------------------------------+
| type | extended community | encoding |
+--------+--------------------+-------------------------------------+
| 0x8008 | redirect AS-2byte | 2-octet AS, 4-octet Value |
| 0x8108 | redirect IPv4 | 4-octet IPv4 Address, 2-octet Value |
| 0x8208 | redirect AS-4byte | 4-octet AS, 2-octet Value |
+--------+--------------------+-------------------------------------+
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 4 plus [RFC5668], Sec.
2.) The low order octet (Sub-Type) of the Redirect Extended
Community remains 0x08, contrasted to 0x02 for Route Targets.
The IANA Registries for BGP Extended Communities [RFC7153] document
was written to update the previously-mentioned IANA registries to
better document BGP Extended Community formats. The IANA
Considerations section below further amends those registry updates in
order to properly document the Flowspec redirect communities.
2. IANA Considerations
2.1. Update to BGP Generic Transitive Experimental Use Extended
Community Sub-Types
IANA is requested to update the "BGP Generic Transitive Experimental
Use Extended Community Sub-Types" registry as follows:
0x08 - Flow spec redirect AS-2byte format. [RFC5575, RFC-to-be]
(Note to RFC Editor - replace RFC-to-be with this RFC number.)
IANA is requested to update the "BGP Transitive Extended Community
Types" registry as follows:
Haas Expires October 12, 2015 [Page 4]
Internet-Draft draft-ietf-idr-flowspec-redirect-rt-bis April 2015
0x81 - Generic Transitive Experimental Use Extended Community
Part 2 (Sub-Types are defined in the "Generic Transitive
Experimental Extended Community Part 2 Sub-Types" Registry)
0x82 - Generic Transitive Experimental Use Extended Community
Part 3 (Sub-Types are defined in the "Generic Transitive
Experimental Extended Community Part 3 Sub-Types" Registry)
2.2. Generic Transitive Experimental Extended Community Part 2 Sub-
Types
IANA is requested to create the "Generic Transitive Experimental Use
Extended Community Part 2 Sub-Types" registry. This registry should
be created under http://www.iana.org/assignments/bgp-extended-
communities/bgp-extended-communities.xhtml. It will contain the
following note:
This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first octet
(the "Type" field) is 0x81.
Registry Name: Generic Transitive Experimental Use Extended Community
Part 2 Sub-Types
RANGE REGISTRATION PROCEDURE REFERENCE
0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME
0x00-0x07 Unassigned
0x08 Flow spec redirect IPv4 format. [RFC-to-be]
0x09-0xff Unassigned
(Note to RFC Editor - replace RFC-to-be with this RFC number.)
2.3. Generic Transitive Experimental Extended Community Part 3 Sub-
Types
IANA is requested to create the "Generic Transitive Experimental Use
Extended Community Part 3 Sub-Types" registry. This registry should
be created under http://www.iana.org/assignments/bgp-extended-
communities/bgp-extended-communities.xhtml. It will contain the
following note:
This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first octet
(the "Type" field) is 0x82.
Haas Expires October 12, 2015 [Page 5]
Internet-Draft draft-ietf-idr-flowspec-redirect-rt-bis April 2015
Registry Name: Generic Transitive Experimental Use Extended Community
Part 2 Sub-Types
RANGE REGISTRATION PROCEDURE REFERENCE
0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME
0x00-0x07 Unassigned
0x08 Flow spec redirect AS-4byte format. [RFC-to-be]
0x09-0xff Unassigned
(Note to RFC Editor - replace RFC-to-be with this RFC number.)
3. Security Considerations
This document introduces no additional security considerations than
those already covered in [RFC5575]. It should be noted that if the
wildcard behavior were actually implemented, this ambiguity may lead
to the installation of Flowspec rules in an incorrect VRF and may
lead to traffic to be incorrectly delivered.
4. Acknowledgements
The contents of this document was raised as part of implementation
discussions of BGP Flowspec with the following individuals:
Andrew Karch (Cisco)
Robert Raszuk
Adam Simpson (Alcatel-Lucent)
Matthieu Texier (Arbor Networks)
Kaliraj Vairavakkalai (Juniper)
5. Normative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009.
Haas Expires October 12, 2015 [Page 6]
Internet-Draft draft-ietf-idr-flowspec-redirect-rt-bis April 2015
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
Specific BGP Extended Community", RFC 5668, October 2009.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, March 2014.
Author's Address
Jeffrey Haas (editor)
Juniper Networks
Email: [email protected]
Haas Expires October 12, 2015 [Page 7]
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
