draft-ietf-idr-bgp-flowspec-oid-01.txt   draft-ietf-idr-bgp-flowspec-oid-02.txt 
Network Working Group James Uttaro Network Working Group James Uttaro
Internet Draft AT&T Internet Draft AT&T
Updates: 5575 Clarence Filsfils Updates: 5575 Clarence Filsfils
Intended Status: Proposed Standard Pradosh Mohapatra Intended Status: Proposed Standard David Smith
Expiration Date: July 2013 David Smith Expiration Date: July 31, 2014 Juan Alcaide
Cisco Cisco
January 22, 2013 Pradosh Mohapatra
Cumulus Networks
January 17, 2014
Revised Validation Procedure for BGP Flow Specifications Revised Validation Procedure for BGP Flow Specifications
draft-ietf-idr-bgp-flowspec-oid-01 draft-ietf-idr-bgp-flowspec-oid-02
Abstract Abstract
This document describes a modification to the validation procedure This document describes a modification to the validation procedure
defined in RFC 5575 for the dissemination of BGP flow specifications. defined in RFC 5575 for the dissemination of BGP flow specifications.
RFC 5575 requires that the originator of the flow specification RFC 5575 requires that the originator of the flow specification
matches the originator of the best-match unicast route for the matches the originator of the best-match unicast route for the
destination prefix embedded in the flow specification. This allows destination prefix embedded in the flow specification. This allows
only BGP speakers within the data forwarding path (such as autonomous only BGP speakers within the data forwarding path (such as autonomous
system border routers) to originate BGP flow specifications. Though system border routers) to originate BGP flow specifications. Though
skipping to change at page 1, line 43 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2013. This Internet-Draft will expire on July 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Specification of Requirements ...................... 2 1 Specification of Requirements ...................... 3
2 Motivation ......................................... 3 2 Motivation ......................................... 3
3 Introduction ....................................... 5 3 Introduction ....................................... 5
4 Revised Validation Procedure ....................... 6 4 Revised Validation Procedure ....................... 6
5 Security Considerations ............................ 7 5 Security Considerations ............................ 7
6 IANA Considerations ................................ 7 6 IANA Considerations ................................ 7
7 Normative References ............................... 7 7 Normative References ............................... 7
8 Acknowledgements ................................... 8 8 Acknowledgements ................................... 8
9 Authors' Addresses ................................. 8 9 Authors' Addresses ................................. 8
1. Specification of Requirements 1. Specification of Requirements
skipping to change at page 6, line 10 skipping to change at page 6, line 10
complex BGP policies. By relaxing the validation procedure for IBGP, complex BGP policies. By relaxing the validation procedure for IBGP,
the proposed modification allows flow specifications to be the proposed modification allows flow specifications to be
distributed in a standard and scalable manner throughout an distributed in a standard and scalable manner throughout an
autonomous system. autonomous system.
4. Revised Validation Procedure 4. Revised Validation Procedure
Step (a) of the validation procedure specified in RFC 5575, section 6 Step (a) of the validation procedure specified in RFC 5575, section 6
is redefined as follows: is redefined as follows:
a) One of the following conditions MUST hold true: a) One of the following conditions MUST hold true:
o The originator of the flow specification matches the o The originator of the flow specification matches the
originator of the best-match unicast route for the originator of the best-match unicast route for the
destination prefix embedded in the flow specification. destination prefix embedded in the flow specification.
o The AS_PATH and AS4_PATH attribute of the flow o The AS_PATH and AS4_PATH attribute of the flow
specification are empty. specification are empty.
o The AS_PATH and AS4_PATH attribute of the flow o The AS_PATH and AS4_PATH attribute of the flow
specification does not contain AS_SET and AS_SEQUENCE specification does not contain AS_SET and AS_SEQUENCE
segments. segments.
An empty AS_PATH and AS4_PATH attribute indicates per [RFC4271] that An empty AS_PATH and AS4_PATH attribute indicates per [RFC4271] that
the flow specification NLRI originated in the same autonomous system the flow specification NLRI originated in the same autonomous system
as the local BGP speaker. Similarly, lack of AS_SET and AS_SEQUENCE as the local BGP speaker. Similarly, lack of AS_SET and AS_SEQUENCE
segments within an AS_PATH and AS4_PATH attribute that is not empty segments within an AS_PATH and AS4_PATH attribute that is not empty
indicates that the flow specification NLRI originated in the same indicates that the flow specification NLRI originated in the same
autonomous system as the local BGP speaker but that the autonomous autonomous system as the local BGP speaker but that the autonomous
system includes a BGP confederation [RFC5065]. With this proposed system includes a BGP confederation [RFC5065]. With this proposed
modification to the RFC 5575 validation procedure, it is now possible modification to the RFC 5575 validation procedure, it is now possible
for an IBGP peer that is not within the data forwarding path to for an IBGP peer that is not within the data forwarding path to
skipping to change at page 8, line 23 skipping to change at page 8, line 22
9. Authors' Addresses 9. Authors' Addresses
James Uttaro James Uttaro
AT&T AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: ju1738@att.com Email: ju1738@att.com
Juan Alcaide
Cisco
7100 Kit Creek Road
Research Triangle Park, NC 27709
USA
Email: jalcaide@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Cisco
Brussels 1000 Brussels 1000
BE BE
Email: cf@cisco.com Email: cf@cisco.com
David Smith
Pradosh Mohapatra
Cisco
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: pmohapat@cisco.com
David J. Smith
Cisco Cisco
111 Wood Avenue South 111 Wood Avenue South
Iselin, NJ 08830 Iselin, NJ 08830
USA USA
E-mail: djsmith@cisco.com Email: djsmith@cisco.com
Pradosh Mohapatra
Cumulus Networks
185 E. Dana Street
Mountain View, CA 94041
USA
Email: mpradosh@yahoo.com
 End of changes. 11 change blocks. 
26 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/