--- 1/draft-ietf-grow-bmp-local-rib-03.txt 2019-06-07 11:13:14.590115569 -0700 +++ 2/draft-ietf-grow-bmp-local-rib-04.txt 2019-06-07 11:13:14.622116385 -0700 @@ -1,21 +1,21 @@ Global Routing Operations T. Evens Internet-Draft S. Bayraktar Updates: 7854 (if approved) M. Bhardwaj Intended status: Standards Track Cisco Systems -Expires: September 25, 2019 P. Lucente +Expires: December 9, 2019 P. Lucente NTT Communications - March 24, 2019 + June 7, 2019 Support for Local RIB in BGP Monitoring Protocol (BMP) - draft-ietf-grow-bmp-local-rib-03 + draft-ietf-grow-bmp-local-rib-04 Abstract The BGP Monitoring Protocol (BMP) defines access to the Adj-RIB-In and locally originated routes (e.g. routes distributed into BGP from protocols such as static) but not access to the BGP instance Loc-RIB. This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the BGP instance Local-RIB, as defined in RFC 4271 the routes that have been selected by the local BGP speaker's Decision Process. These are the routes over all peers, locally @@ -29,21 +29,21 @@ 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 https://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 September 25, 2019. + This Internet-Draft will expire on December 9, 2019. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -335,21 +335,21 @@ as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| Reserved | +-+-+-+-+-+-+-+-+ o The F flag indicates that the Loc-RIB is filtered. This indicates that the Loc-RIB does not represent the complete routing table. - The remaining bits are reserved for future use. They SHOULD be + The remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt. 5. Loc-RIB Monitoring Loc-RIB contains all routes from BGP peers as well as any and all routes redistributed or otherwise locally originated. In this context, only the BGP instance Loc-RIB is included. Routes from other routing protocols that have not been redistributed, originated by or into BGP, or received via Adj-RIB-In are not considered. @@ -413,36 +413,36 @@ The following peer UP information TLV type is added: o Type = 3: VRF/Table Name. The Information field contains an ASCII string whose value MUST be equal to the value of the VRF or table name (e.g. RD instance name) being conveyed. The string size MUST be within the range of 1 to 255 bytes. The VRF/Table Name TLV is optionally included. For consistency, it is RECOMMENDED that the VRF/Table Name always be included. The - default value of "global" SHOULD be used for the default Loc-RIB + default value of "global" MUST be used for the default Loc-RIB instance with a zero-filled distinguisher. If the TLV is - included, then it SHOULD also be included in the Peer Down + included, then it MUST also be included in the Peer Down notification. 5.3. Peer Down Notification - Peer down notification SHOULD use reason code TBD3. Following the + Peer down notification MUST use reason code TBD3. Following the reason is data in TLV format. The following peer Down information TLV type is defined: o Type = 3: VRF/Table Name. The Information field contains an ASCII string whose value MUST be equal to the value of the VRF or table name (e.g. RD instance name) being conveyed. The string size MUST be within the range of 1 to 255 bytes. The VRF/Table Name - informational TLV SHOULD be included if it was in the Peer UP. + informational TLV MUST be included if it was in the Peer UP. 5.4. Route Monitoring Route Monitoring messages are used for initial synchronization of the Loc-RIB. They are also used to convey incremental Loc-RIB changes. As defined in section 4.3 [RFC7854], "Following the common BMP header and per-peer header is a BGP Update PDU." 5.4.1. ASN Encoding @@ -457,21 +457,21 @@ to BMP receivers. With state compression, only the final resultant updates are sent. For example, prefix 10.0.0.0/8 is updated in the Loc-RIB 5 times within 1 second. State compression of BMP route monitor messages results in only the final change being transmitted. The other 4 changes are suppressed because they fall within the compression interval. If no compression was being used, all 5 updates would have been transmitted. - A BMP receiver SHOULD expect that Loc-RIB route monitoring + A BMP receiver should expect that Loc-RIB route monitoring granularity can be different by BMP sender implementation. 5.5. Route Mirroring Route mirroring is not applicable to Loc-RIB. 5.6. Statistics Report Not all Stat Types are relevant to Loc-RIB. The Stat Types that are relevant are listed below: