draft-ietf-idr-error-handling-12.txt   draft-ietf-idr-error-handling-13.txt 
Internet Engineering Task Force E. Chen, Ed. Internet Engineering Task Force E. Chen, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Updates: 1997, 4271, 4360, 4456, 4760, J. Scudder, Ed. Updates: 1997, 4271, 4360, 4456, 4760, J. Scudder, Ed.
5543, 5701, 6368, 6790 (if Juniper Networks 5543, 5701, 6368, 6790 (if Juniper Networks
approved) P. Mohapatra approved) P. Mohapatra
Intended status: Standards Track Sproute Networks Intended status: Standards Track Sproute Networks
Expires: December 13, 2014 K. Patel Expires: December 15, 2014 K. Patel
Cisco Systems, Inc. Cisco Systems, Inc.
June 11, 2014 June 13, 2014
Revised Error Handling for BGP UPDATE Messages Revised Error Handling for BGP UPDATE Messages
draft-ietf-idr-error-handling-12 draft-ietf-idr-error-handling-13
Abstract Abstract
According to the base BGP specification, a BGP speaker that receives According to the base BGP specification, a BGP speaker that receives
an UPDATE message containing a malformed attribute is required to an UPDATE message containing a malformed attribute is required to
reset the session over which the offending attribute was received. reset the session over which the offending attribute was received.
This behavior is undesirable as a session reset would impact not only This behavior is undesirable as a session reset would impact not only
routes with the offending attribute, but also other valid routes routes with the offending attribute, but also other valid routes
exchanged over the session. This document partially revises the exchanged over the session. This document partially revises the
error handling for UPDATE messages, and provides guidelines for the error handling for UPDATE messages, and provides guidelines for the
authors of documents defining new attributes. Finally, it revises authors of documents defining new attributes. Finally, it revises
the error handling procedures for a number of existing attributes. the error handling procedures for a number of existing attributes.
This document updates error handling for RFCs 1997, 4271, 4360, 4456, This document updates error handling for RFCs 1997, 4271, 4360, 4456,
4760 and 5701. 4760, 5543, 5701, 6368 and 6790.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 13, 2014. This Internet-Draft will expire on December 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Error-Handling Approaches . . . . . . . . . . . . . . . . . . 4 2. Error-Handling Approaches . . . . . . . . . . . . . . . . . . 4
3. Revision to BGP UPDATE Message Error Handling . . . . . . . . 4 3. Revision to BGP UPDATE Message Error Handling . . . . . . . . 4
4. Attribute Length Fields . . . . . . . . . . . . . . . . . . . 6 4. Attribute Length Fields . . . . . . . . . . . . . . . . . . . 6
5. Parsing of NLRI Fields . . . . . . . . . . . . . . . . . . . 7 5. Parsing of NLRI Fields . . . . . . . . . . . . . . . . . . . 7
5.1. Encoding NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Encoding NLRI . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Missing NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Missing NLRI . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Syntactic Correctness of NLRI Fields . . . . . . . . . . 8 5.3. Syntactic Correctness of NLRI Fields . . . . . . . . . . 8
5.4. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 8
6. Operational Considerations . . . . . . . . . . . . . . . . . 9 6. Operational Considerations . . . . . . . . . . . . . . . . . 9
7. Error Handling Procedures for Existing Attributes . . . . . . 9 7. Error Handling Procedures for Existing Attributes . . . . . . 10
7.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . 11 7.4. MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . 11
7.5. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . 11 7.5. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . 11
7.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 11 7.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 12
7.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 12 7.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 12
7.8. Community . . . . . . . . . . . . . . . . . . . . . . . . 12 7.8. Community . . . . . . . . . . . . . . . . . . . . . . . . 12
7.9. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 12 7.9. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 12
7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 12 7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 13
7.11. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 13 7.11. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 13
7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 13 7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 14
7.13. Traffic Engineering path attribute . . . . . . . . . . . 13 7.13. Traffic Engineering path attribute . . . . . . . . . . . 14
7.14. Extended Community . . . . . . . . . . . . . . . . . . . 14 7.14. Extended Community . . . . . . . . . . . . . . . . . . . 14
7.15. IPv6 Address Specific BGP Extended Community Attribute . 14 7.15. IPv6 Address Specific BGP Extended Community Attribute . 14
7.16. BGP Entropy Label Capability Attribute . . . . . . . . . 14 7.16. BGP Entropy Label Capability Attribute . . . . . . . . . 15
7.17. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 14 7.17. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Guidance for Authors of BGP Specifications . . . . . . . . . 15 8. Guidance for Authors of BGP Specifications . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
According to the base BGP specification [RFC4271], a BGP speaker that According to the base BGP specification [RFC4271], a BGP speaker that
receives an UPDATE message containing a malformed attribute is receives an UPDATE message containing a malformed attribute is
required to reset the session over which the offending attribute was required to reset the session over which the offending attribute was
received. This behavior is undesirable as a session reset would received. This behavior is undesirable as a session reset would
impact not only routes with the offending attribute, but also other impact not only routes with the offending attribute, but also other
valid routes exchanged over the session. In the case of optional valid routes exchanged over the session. In the case of optional
transitive attributes, the behavior is especially troublesome and may transitive attributes, the behavior is especially troublesome and may
skipping to change at page 4, line 10 skipping to change at page 4, line 10
maintaining protocol correctness to the extent possible. This can be maintaining protocol correctness to the extent possible. This can be
achieved largely by maintaining the established session and keeping achieved largely by maintaining the established session and keeping
the valid routes exchanged, but removing the routes carried in the the valid routes exchanged, but removing the routes carried in the
malformed UPDATE from the routing system. malformed UPDATE from the routing system.
This document partially revises the error handling for UPDATE This document partially revises the error handling for UPDATE
messages, and provides guidelines for the authors of documents messages, and provides guidelines for the authors of documents
defining new attributes. Finally, it revises the error handling defining new attributes. Finally, it revises the error handling
procedures for a number of existing attributes. Specifically, the procedures for a number of existing attributes. Specifically, the
error handling procedures of [RFC1997], [RFC4271], [RFC4360], error handling procedures of [RFC1997], [RFC4271], [RFC4360],
[RFC4456], [RFC4760] and [RFC5701] are revised. [RFC4456], [RFC4760], [RFC5543], [RFC5701], [RFC6368] and [RFC6790]
are revised.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Error-Handling Approaches 2. Error-Handling Approaches
In this document we refer to four different approaches to handling In this document we refer to four different approaches to handling
skipping to change at page 8, line 45 skipping to change at page 8, line 47
the attribute. the attribute.
o The attribute flags of the attribute are inconsistent with those o The attribute flags of the attribute are inconsistent with those
specified in [RFC4760]. specified in [RFC4760].
o The length of the MP_UNREACH_NLRI attribute is less than 3, or the o The length of the MP_UNREACH_NLRI attribute is less than 3, or the
length of the MP_REACH_NLRI attribute is less than 5. length of the MP_REACH_NLRI attribute is less than 5.
5.4. Typed NLRI 5.4. Typed NLRI
Certain address families, for example MVPN [RFC7117] and EVPN Certain address families, for example MCAST-VPN [RFC6514], MCAST-VPLS
[I-D.ietf-l2vpn-evpn] have NLRI that are typed. Since supported type [RFC7117] and EVPN [I-D.ietf-l2vpn-evpn] have NLRI that are typed.
values within the address family are not expressed in the MP-BGP Since supported type values within the address family are not
capability [RFC4760], it is possible for a BGP speaker to advertise expressed in the MP-BGP capability [RFC4760], it is possible for a
support for the given address family and sub-address family while BGP speaker to advertise support for the given address family and
still not supporting a particular type of NLRI within that AFI/SAFI. sub-address family while still not supporting a particular type of
NLRI within that AFI/SAFI.
A BGP speaker advertising support for such a typed address family A BGP speaker advertising support for such a typed address family
MUST handle routes with unrecognized NLRI types within that address MUST handle routes with unrecognized NLRI types within that address
family by discarding them, unless the relevant specification for that family by discarding them, unless the relevant specification for that
address family specifies otherwise. address family specifies otherwise.
6. Operational Considerations 6. Operational Considerations
Although the "treat-as-withdraw" error-handling behavior defined in Although the "treat-as-withdraw" error-handling behavior defined in
Section 2 makes every effort to preserve BGP's correctness, we note Section 2 makes every effort to preserve BGP's correctness, we note
skipping to change at page 11, line 18 skipping to change at page 11, line 23
According to [RFC4271] the attribute is considered malformed if it is According to [RFC4271] the attribute is considered malformed if it is
syntactically incorrect. To quote from that document, "Syntactic syntactically incorrect. To quote from that document, "Syntactic
correctness means that the NEXT_HOP attribute represents a valid IP correctness means that the NEXT_HOP attribute represents a valid IP
host address", but it does not go on to define what it means to be a host address", but it does not go on to define what it means to be a
"valid IP host address". Therefore: "valid IP host address". Therefore:
An IP host address SHOULD be considered invalid if it appears in the An IP host address SHOULD be considered invalid if it appears in the
"IANA IPv4 Special-Purpose Address Registry" [IANA-IPV4] and either "IANA IPv4 Special-Purpose Address Registry" [IANA-IPV4] and either
the "destination" or the "forwardable" boolean in that registry is the "destination" or the "forwardable" boolean in that registry is
given as "false". An implementation MAY provide a means to modify given as "false". An implementation SHOULD provide a means to modify
the list of invalid host addresses by configuration -- these are the list of invalid host addresses by configuration -- these are
sometimes referred to as "Martians". sometimes referred to as "Martians".
An UPDATE message with a malformed NEXT_HOP attribute SHALL be An UPDATE message with a malformed NEXT_HOP attribute SHALL be
handled using the approach of "treat-as-withdraw". handled using the approach of "treat-as-withdraw".
7.4. MULTI_EXIT_DISC 7.4. MULTI_EXIT_DISC
The attribute is considered malformed if its length is not 4 The attribute is considered malformed if its length is not 4
[RFC4271]. [RFC4271].
skipping to change at page 13, line 19 skipping to change at page 13, line 27
7.11. MP_REACH_NLRI 7.11. MP_REACH_NLRI
[RFC4760] references the error-handling of the base BGP specification [RFC4760] references the error-handling of the base BGP specification
for validation of the next hop. ("The rules for the next hop for validation of the next hop. ("The rules for the next hop
information are the same as the rules for the information carried in information are the same as the rules for the information carried in
the NEXT_HOP BGP attribute".) Thus just as in Section 7.3 we must the NEXT_HOP BGP attribute".) Thus just as in Section 7.3 we must
consider what it means for the Next Hop field of the MP_REACH consider what it means for the Next Hop field of the MP_REACH
attribute to be a "valid host address": attribute to be a "valid host address":
o If the Next Hop field is an IPv4 address, it SHOULD be considered o If the Next Hop field contains an IPv4 address (possibly as a sub-
invalid if it appears in the "IANA IPv4 Special-Purpose Address field), the field SHOULD be considered invalid if the IPv4 address
Registry" [IANA-IPV4] and either the "destination" or the appears in the ""IANA IPv4 Special-Purpose Address Registry"
"forwardable" boolean in that registry is given as "false". [IANA-IPV4] and either the "destination" or the "forwardable"
boolean in that registry is given as "false".
o If the Next Hop field is an IPv6 address, it SHOULD be considered o If the Next Hop field contains an IPv6 address (possibly as a sub-
invalid if it appears in the "IANA IPv6 Special-Purpose Address field), the field SHOULD be considered invalid if the IPv6 address
Registry" [IANA-IPV6] and either the "destination" or the appears in the "IANA IPv6 Special-Purpose Address Registry"
"forwardable" boolean in that registry is given as "false". [IANA-IPV6], the address is not an IPv4-mapped IPv6 address, and
either the "destination" or the "forwardable" boolean in that
registry is given as "false".
o If the Next Hop field contains an IPv4-mapped IPv6 address
(possibly as a sub-field), the field SHOULD be considered invalid
unless the use of such addresses has been explicitly allowed for
the particular AFI/SAFI that occurs in this MP_REACH_NLRI
attribute. (E.g., see [RFC4659] and [RFC4798].)
o If the Next Hop field is some other form of address, it should be o If the Next Hop field is some other form of address, it should be
considered invalid in circumstances analogous to the above -- if considered invalid in circumstances analogous to the above -- if
it is found in the relevant IANA special-purpose address registry it is found in the relevant IANA special-purpose address registry
(if any) and its "destination" or "forwardable" boolean is given (if any) and its "destination" or "forwardable" boolean is given
as "false". as "false".
o An implementation MAY provide a means to modify the list of o An implementation SHOULD provide a means to modify the list of
invalid host addresses by configuration -- these are sometimes invalid host addresses by configuration -- these are sometimes
referred to as "Martians". referred to as "Martians".
Section 3 and Section 5 provide further discussion of the handling of Section 3 and Section 5 provide further discussion of the handling of
this attribute. this attribute.
7.12. MP_UNREACH_NLRI 7.12. MP_UNREACH_NLRI
Section 3 and Section 5 discuss the handling of this attribute. Section 3 and Section 5 discuss the handling of this attribute.
7.13. Traffic Engineering path attribute 7.13. Traffic Engineering path attribute
The error handling of [RFC5543] is revised as follows. We note that [RFC5543] does not detail what constitutes
"malformation" for the Traffic Engineering path attribute. A future
TBD update to that specification may provide more guidance. In the
interim, an implementation that determines (for whatever reason) that
an UPDATE message contains a malformed Traffic Engineering path
attribute MUST handle it using the approach of "treat-as-withdraw".
7.14. Extended Community 7.14. Extended Community
The error handling of [RFC4360] is revised as follows: The error handling of [RFC4360] is revised as follows:
The Extended Community attribute SHALL be considered malformed if its The Extended Community attribute SHALL be considered malformed if its
length is not a nonzero multiple of 8. length is not a nonzero multiple of 8.
An UPDATE message with a malformed Extended Community attribute SHALL An UPDATE message with a malformed Extended Community attribute SHALL
be handled using the approach of "treat-as-withdraw". be handled using the approach of "treat-as-withdraw".
skipping to change at page 17, line 35 skipping to change at page 18, line 12
Autonomous System (AS) Number Space", RFC 6793, December Autonomous System (AS) Number Space", RFC 6793, December
2012. 2012.
12.2. Informative References 12.2. Informative References
[I-D.ietf-l2vpn-evpn] [I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-07 (work in progress), May 2014. evpn-07 (work in progress), May 2014.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C.
Kodeboniya, "Multicast in Virtual Private LAN Service Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, February 2014. (VPLS)", RFC 7117, February 2014.
Authors' Addresses Authors' Addresses
Enke Chen (editor) Enke Chen (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: enkechen@cisco.com Email: enkechen@cisco.com
 End of changes. 20 change blocks. 
36 lines changed or deleted 62 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/