< draft-ietf-idr-rfc5575bis-16.txt   draft-ietf-idr-rfc5575bis-17.txt >
IDR Working Group C. Loibl IDR Working Group C. Loibl
Internet-Draft Next Layer Communications Internet-Draft Next Layer Communications
Obsoletes: 5575,7674 (if approved) S. Hares Obsoletes: 5575,7674 (if approved) S. Hares
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: December 2, 2019 R. Raszuk Expires: December 20, 2019 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
May 31, 2019 June 18, 2019
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-16 draft-ietf-idr-rfc5575bis-17
Abstract Abstract
This document defines a Border Gateway Protocol Network Layer This document defines a Border Gateway Protocol Network Layer
Reachability Information (BGP NLRI) encoding format that can be used Reachability Information (BGP NLRI) encoding format that can be used
to distribute traffic Flow Specifications. This allows the routing to distribute traffic Flow Specifications. This allows the routing
system to propagate information regarding more specific components of system to propagate information regarding more specific components of
the traffic aggregate defined by an IP destination prefix. the traffic aggregate defined by an IP destination prefix.
It specifies IPv4 traffic Flow Specifications via a BGP NLRI which It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 2, 2019. This Internet-Draft will expire on December 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 17, line 28 skipping to change at page 17, line 28
The first step of the BGP Route Selection procedure (Section 9.1.2 of The first step of the BGP Route Selection procedure (Section 9.1.2 of
[RFC4271] is to exclude from the selection procedure routes that are [RFC4271] is to exclude from the selection procedure routes that are
considered non-feasible. In the context of IP routing information, considered non-feasible. In the context of IP routing information,
this step is used to validate that the NEXT_HOP attribute of a given this step is used to validate that the NEXT_HOP attribute of a given
route is resolvable. route is resolvable.
The concept can be extended, in the case of Flow Specification NLRI, The concept can be extended, in the case of Flow Specification NLRI,
to allow other validation procedures. to allow other validation procedures.
A Flow Specification NLRI must be validated such that it is A Flow Specification NLRI must be validated such that it is
considered feasible if and only if: considered feasible if and only if all of the below is true:
a) The originator of the Flow Specification matches the originator a) A destination prefix component is embedded in the Flow
Specification.
b) The originator of the Flow Specification matches the originator
of the best-match unicast route for the destination prefix of the best-match unicast route for the destination prefix
embedded in the Flow Specification. embedded in the Flow Specification.
b) There are no more specific unicast routes, when compared with c) There are no more specific unicast routes, when compared with
the flow destination prefix, that has been received from a the flow destination prefix, that has been received from a
different neighboring AS than the best-match unicast route, which different neighboring AS than the best-match unicast route, which
has been determined in step a). has been determined in rule b).
Rule a) MAY be relaxed by configuration, permitting Flow
Specifications that include no destination prefix component. If such
is the case, rules b) and c) are moot and MUST be disregarded.
By originator of a BGP route, we mean either the BGP originator path By originator of a BGP route, we mean either the BGP originator path
attribute, as used by route reflection, or the transport address of attribute, as used by route reflection, or the transport address of
the BGP peer, if this path attribute is not present. the BGP peer, if this path attribute is not present.
BGP implementations MUST also enforce that the AS_PATH attribute of a BGP implementations MUST also enforce that the AS_PATH attribute of a
route received via the External Border Gateway Protocol (eBGP) route received via the External Border Gateway Protocol (eBGP)
contains the neighboring AS in the left-most position of the AS_PATH contains the neighboring AS in the left-most position of the AS_PATH
attribute. While this rule is optional in the BGP specification, it attribute. While this rule is optional in the BGP specification, it
becomes necessary to enforce it for security reasons. becomes necessary to enforce it for security reasons.
 End of changes. 8 change blocks. 
8 lines changed or deleted 15 lines changed or added

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