< draft-idr-bgp-route-refresh-options-00.txt		draft-idr-bgp-route-refresh-options-01.txt >
	Network Working Group K. Patel		Network Working Group K. Patel
	Internet-Draft A. Vyavaharkar		Internet-Draft A. Vyavaharkar
	Intended status: Standards Track N. Fazlollahi		Intended status: Standards Track N. Fazlollahi
	Expires: January 09, 2017 Cisco Systems		Expires: May 18, 2017 Cisco Systems
	A. Przygienda		A. Przygienda
	Juniper Networks		Juniper Networks
	July 08, 2016		November 14, 2016
	Extension to BGP's Route Refresh Message		Extension to BGP's Route Refresh Message
	draft-idr-bgp-route-refresh-options-00.txt		draft-idr-bgp-route-refresh-options-01.txt
	Abstract		Abstract
	[RFC2918] defines a route refresh capability to be exchanged between		[RFC2918] defines a route refresh capability to be exchanged between
	BGP speakers. BGP speakers that support this capability are		BGP speakers. BGP speakers that support this capability are
	advertising that they can resend the entire BGP Adj-RIB-Out on		advertising that they can resend the entire BGP Adj-RIB-Out on
	receipt of a refresh request. By supporting this capability, BGP		receipt of a refresh request. By supporting this capability, BGP
	speakers are more flexible in applying any inbound routing policy		speakers are more flexible in applying any inbound routing policy
	changes as they no longer have to store received routes in their		changes as they no longer have to store received routes in their
	unchanged form or reset the session when an inbound routing policy		unchanged form or reset the session when an inbound routing policy
	skipping to change at page 2, line 4 ¶		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). 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 January 09, 2017.		This Internet-Draft will expire on May 18, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 44 ¶		skipping to change at page 2, line 44 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Use Case Examples . . . . . . . . . . . . . . . . . . . . 3		1.1. Use Case Examples . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Route Refresh Options Capability . . . . . . . . . . . . . . 4		3. Route Refresh Options Capability . . . . . . . . . . . . . . 4
	4. Route Refresh Sub-Types . . . . . . . . . . . . . . . . . . . 4		4. Route Refresh Sub-Types . . . . . . . . . . . . . . . . . . . 4
	5. Route Refresh Option format . . . . . . . . . . . . . . . . . 5		5. Route Refresh Option format . . . . . . . . . . . . . . . . . 5
	6. Route Refresh Option Length . . . . . . . . . . . . . . . . . 6		6. Route Refresh Option Length . . . . . . . . . . . . . . . . . 6
	7. Route Refresh ID . . . . . . . . . . . . . . . . . . . . . . 6		7. Route Refresh ID . . . . . . . . . . . . . . . . . . . . . . 6
	8. Route Refresh Option Flags . . . . . . . . . . . . . . . . . 7		8. Route Refresh Option Flags . . . . . . . . . . . . . . . . . 7
	9. Route Refresh Options . . . . . . . . . . . . . . . . . . . . 7		9. Route Refresh Options . . . . . . . . . . . . . . . . . . . . 8
	10. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10		11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 11		13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	15.1. Normative References . . . . . . . . . . . . . . . . . . 12		15.1. Normative References . . . . . . . . . . . . . . . . . . 12
	15.2. Information References . . . . . . . . . . . . . . . . . 12		15.2. Information References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	[RFC2918] defines a route refresh capability to be exchanged between		[RFC2918] defines a route refresh capability to be exchanged between
	BGP speakers. BGP speakers that support this capability are		BGP speakers. BGP speakers that support this capability are
	advertising that they can resend the entire BGP Adj-RIB-Out on		advertising that they can resend the entire BGP Adj-RIB-Out on
	receipt of a refresh request. By supporting this capability, BGP		receipt of a refresh request. By supporting this capability, BGP
	speakers are more flexible in applying inbound routing policy changes		speakers are more flexible in applying inbound routing policy changes
	as they no longer have to store copies of received routes in their		as they no longer have to store copies of received routes in their
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	HID under [RFC1982].		HID under [RFC1982].
	Value of 0 SHOULD NOT be used as Refresh ID.		Value of 0 SHOULD NOT be used as Refresh ID.
	The sending speaker MUST NOT reorder the BoRR messages on sending in		The sending speaker MUST NOT reorder the BoRR messages on sending in
	case it received multiple requests, i.e., the BoRRs MUST follow in		case it received multiple requests, i.e., the BoRRs MUST follow in
	the same sequence as the requested Route Refresh IDs.		the same sequence as the requested Route Refresh IDs.
	8. Route Refresh Option Flags		8. Route Refresh Option Flags
	This draft defines route refresh option flags to		This draft defines route refresh option flags
	o specify whether the receiving BGP speaker MUST logically OR the		o C - to indicate that the receiving BGP speaker MUST clear
	attached options or logically AND them. When the flag is clear,		immediately all the received Route Refresh Requests with Options,
	the router on the receiving end SHOULD logically AND the options		either pending or being processed. EoRRs MUST NOT be sent. The
	and only refresh routes that match all received options. If the		Refresh ID# on the request is free of restrictions and MUST be set
	option flag is set, the router SHOULD select routes that match		as first number in the sequence number space per [RFC1982]. The C
	using a logical OR of the options. In any case the set of routes		flag MUST NOT be set on BoRR or EoRR messages and CAN be used only
	sent between the according BoRR and EoRR MUST contain at least the		with refresh requests.
	logically requested set.
	o indicate that the receiving BGP speaker MUST clear immediately all		o O - to specify whether the receiving BGP speaker MUST logically OR
	the received Route Refresh Requests with Options, either pending		the attached options or logically AND them. When the flag is
	or being processed. EoRRs MUST NOT be sent. The Refresh ID# on		clear, the router on the receiving end SHOULD logically AND the
	the request is free of restrictions and MUST be set as first		options and only refresh routes that match all received options.
	number in the sequence number space per [RFC1982]. The C flag		If the option flag is set, the router SHOULD select routes that
	MUST NOT be set on BoRR or EoRR messages and CAN be used only with		match using a logical OR of the options. In any case the set of
	refresh requests.		routes sent between the according BoRR and EoRR MUST contain at
			least the logically requested set.
			o S - to indicate a refresh is being spontaneously originated by the
			BGP speaker. The receiving BGP speaker MUST immediately clear all
			their pending Route Refresh requests with the sending peer. The
			Refresh ID# on the request MUST be set as the most distant number
			in the sequence number space as defined in [RFC1982] effectively
			ensuring that the receiving speaker can safely flush pending
			requests and restart the sequence numbering.
	The precise format is indicated below		The precise format is indicated below
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| .... |C|O| R |		| .... |C|O|S|R|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	C Clear pending requests and reset Refresh ID# space.		C Clear pending requests and reset Refresh ID# space.
	O Use logical OR of attached options		O Use logical OR of attached options
	R Reserved bits		S Synchronize sequence numbers
			R Reserved bit
	9. Route Refresh Options		9. Route Refresh Options
	This draft introduces new options carried within the Route Refresh		This draft introduces new options carried within the Route Refresh
	message as shown in the following figure		message as shown in the following figure
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Value |		| Type | Length | Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value (cont'd). |		| Value (cont'd). |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The option Type is a 1 octet field that uniquely identifies		The option Type is a 1 octet field that uniquely identifies
	individual options. The Length is a 2 octet field that contains the		individual options. The Length is a 2 octet field that contains the
	length of the option Value field in octets. The option Value is a		length of the option Value field in octets. The option Value is a
	variable length field that is interpreted according to the value of		variable length field that is interpreted according to the value of
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 37 ¶
	The BGP speaker requesting a refresh from its peers SHOULD maintain a		The BGP speaker requesting a refresh from its peers SHOULD maintain a
	locally configurable upper bound on how long it will keep matching		locally configurable upper bound on how long it will keep matching
	stale routes once a BoRR has been received. Each subsequent BoRR		stale routes once a BoRR has been received. Each subsequent BoRR
	SHOULD reset this period so that any remaining stale routes are only		SHOULD reset this period so that any remaining stale routes are only
	flushed after the last BoRR has been received in case there are		flushed after the last BoRR has been received in case there are
	multiple back-to-back refreshes being sent out and the last matching		multiple back-to-back refreshes being sent out and the last matching
	EoRR is never received or arrives too late. This is an		EoRR is never received or arrives too late. This is an
	implementation specific detail.		implementation specific detail.
	11. Error Handling		A BGP speaker may spontaneously originate a refresh to one or more of
			its peers depending on operator intervention, or due to a policy or
			configuration change, etc. In such a case, the speaker MUST refresh
			the entire Adj-RIB-Out. The speaker MUST also send BoRR/EoRR with
			the options field with the 'S' flag set and a sequence number which
			is the most distant from the sequence numbers that are currently in
			use as per [RFC1982]. On receiving BoRR/EoRR with options and the
			'S' flag set, the BGP speaker MUST discard any pending route
			refreshes it has originated to the remote peer and treat the incoming
			refresh as a full Adj-RIB-Out refresh. The receiving peer MUST also
			reset the refresh ID space and start using the one in the incoming
			message.
			11. Error Handling
	The handling of malformed options MUST follow the procedures		The handling of malformed options MUST follow the procedures
	mentioned in [RFC7606]. This draft obsoletes some of the error		mentioned in [RFC7606]. This draft obsoletes some of the error
	handling procedures in [RFC7313] if the Route Refresh Options		handling procedures in [RFC7313] if the Route Refresh Options
	Capability is sent. In addition, this draft mandates the following		Capability is sent. In addition, this draft mandates the following
	behavior at the receiver of the route refresh request upon detection		behavior at the receiver of the route refresh request upon detection
	of:		of:
	Length errors - If the message length minus the fixed-size message		Length errors - If the message length minus the fixed-size message
	header is less than 4, the procedure in [RFC7313] MUST be followed.		header is less than 4, the procedure in [RFC7313] MUST be followed.
	Also, if the overall length of all the options or any individual		Also, if the overall length of all the options or any individual
End of changes. 15 change blocks.
	29 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/