BGP Monitoring Protocol (BMP)
draft-ietf-grow-bmp-17

[Ballot comment]
thanks for addressing my discuss points:

The statements on authenticated access and confidentiality are helpful, but this is a new protocol and should not start out with the security property levels of the current BGP deployments.  Efforts have been made to publish RFCs to fix BGP security and the vulnerabilities have been published - even in the Washington Post.  I'd like to see more security required for the properties mentioned to prevent active and passive attacks getting dumps of the BGP data, which was not previously available.  If this is not possible per the suggestions below, please explain why.  If there is a good reason, it would be helpful to remove the text that says its okay to leave security out because BGP isn't secure and just include the security considerations.

Now for specifics:

1. In the Security considerations, it is not only a passive attacker, but also an active one that could gain access to the session if it is not encrypted (protected for confidentiality).  An active attacker might change routes causing network disruption.  A passive attacker might better understand the possible paths to an AS, assisting with a more effective DDoS attack.  The latter point is important to consider in the first paragraph of this section that currently says,
  "although it's hard to consider the content of BGP routes in the
  public Internet to be confidential,"

I think this is a bit of an overstatement as the exact routes and paths are not published for each router and could be used for DoS attacks - for example taking out one or more paths to a network AS.

What I am suggesting for #1 is a simple text change to address the fuller set of security considerations.
Change from:
  Unless a transport that provides confidentiality is used,
  a passive attacker could gain access to BMP data in flight.
To:
  Unless a transport that provides confidentiality is used,
  a passive or active attacker could gain access to or tamper the BMP data in flight.


2. The last paragraph would be the right place to require session encryption and authentication for sessions (unless there is a good explanation as to why this is not needed).  If the transport may vary, then it's okay to leave IPsec as a suggestion.  It would be nice if there was an MTI for transport, so the security protections could be consistent and interoperability would be easier between implementations.  This also came up in the SecDir review.
https://www.ietf.org/mail-archive/web/secdir/current/msg06011.html
In any case, it would be good to discuss this and see if there are good reasons to leave it as-is or to change the text to improve security, preventing a few attack types.

[Ballot comment]

I'm clearing my discuss as promised as you've now added
text on using IPsec that would work if someone wanted to
do that. I'm still sad that you didn't decide to write down
how to do this over TLS, as that'd really be more likely to
be used I think. But perhaps you'll do that in future, which'd
be good. (Or if you wanted to do that for this document
still, I'd be happier:-) In any case, the discuss is cleared,
but I'm also happy to continue chatting about how to do
TLS for this if that's useful.


Old comments below, I didn't check these. Happy to chat about
'em more, but we don't have to unless you want to.

Separate to the discuss, I have some non-blocking points,
that I think resonate with Kathleen's discuss:

Why is using TLS not a no-brainer for this?  Given the likes
of the Belgacom and Gemalto reports, I would love to
understand why people are still willing to buy and sell
equipment without such basic features. The "explanation"
that nobody needs it or nobody provides it seems off base
here - this is new code and a new interface, and the
relevant security protocols (SSH, IPsec and TLS) are all
nearly or more than 20 years old. And that is all the more
the case for a new protocol like this that is not likely in
the critical path and where the monitoring statiion may be
off to the side so the traffic flows via BMP in places where
BGP doesn't go implying different threat levels, that may
need different protection.

My best guess as to causes for now is that people are just
used to doing nothing and have done that for so long they
seem to think that doing nothing is the only possibility.
(That's how business models get disrupted isn't it?) Can you
educate me some more on this?

(And yes, I get that all the stuff as to why AO isn't
available for BGP, but this is not BGP. It's our apparent
need to keep the security level down at the "crap" marker
that I don't get.)

[Ballot discuss]

Hi, this is an update of my discuss. After some discussion
the authors changed from:

OLD:

  Where the security considerations outlined above are a concern, users
  of this protocol should consider using some type of transport that
  provides mutual authentication, data integrity and transport
  protection, such as IPsec [RFC4303] or TCP-AO [RFC5925].  If
  confidentiality is considered a concern, a transport providing that
  as well could be selected.

NEW:

  This document does not specify any security mechanism for BMP.

I do not believe that it is ok to merely state that one is not
paying attention to IETF BCPs (BCP61 specifically) but one
needs to explain why. Hence my original suggestion which
was:

"This is an inherently insecure protocol for no particularly
good reason and mostly due to the lack of implementation of
basic security mechanisms (SSH, TLS) but also due to a lack
of customer/operator pressure to ensure those are present,
usable and interoperate, despite evidence that attacks on
the links over which this data will be sent are ongoing."

I would like to talk about the right text to add here. My
belief (having chatted with a few folks but not everyone)
was that some people would be ok with saying you ought
implement IPsec, others would be ok with you ought do
TLS so backing right back down to "it's ok and not sad to
do nothing" seems wrong to me.

[Ballot comment]

I didn't check these. Happy to chat about 'em more, but
we don't have to unless you want to.

Separate to the discuss, I have some non-blocking points,
that I think resonate with Kathleen's discuss:

Why is using TLS not a no-brainer for this?  Given the likes
of the Belgacom and Gemalto reports, I would love to
understand why people are still willing to buy and sell
equipment without such basic features. The "explanation"
that nobody needs it or nobody provides it seems off base
here - this is new code and a new interface, and the
relevant security protocols (SSH, IPsec and TLS) are all
nearly or more than 20 years old. And that is all the more
the case for a new protocol like this that is not likely in
the critical path and where the monitoring statiion may be
off to the side so the traffic flows via BMP in places where
BGP doesn't go implying different threat levels, that may
need different protection.

My best guess as to causes for now is that people are just
used to doing nothing and have done that for so long they
seem to think that doing nothing is the only possibility.
(That's how business models get disrupted isn't it?) Can you
educate me some more on this?

(And yes, I get that all the stuff as to why AO isn't
available for BGP, but this is not BGP. It's our apparent
need to keep the security level down at the "crap" marker
that I don't get.)

[Ballot comment]
Considering that
1. BMP will simply transmit the PDU
2. The use cases is monitoring
3. The correlation between BMP and draft-ietf-idr-bgp-model is possible (at least manually)
4. It's implemented today
I'll remove my DISCUSS


COMMENT:
- From the write-up:

-- The BMP protocol has been a GROW document for quite sometime.  The
-- length of time has allowed the document to have multiple implementations
-- completed, along with incorporating working group feedback into the spec
-- and polishing the document.

Btw, don't forget, for future documents, the experimental RFC 6982 "Improving Awareness of Running Code: The Implementation Status Section"

-  following nits need to be addressed in the document.

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to contain a disclaimer for pre-RFC5378 work, but was
    first submitted on or after 10 November 2008.  The disclaimer is usually
    necessary only for documents that revise or obsolete older RFCs, and that
    take significant amounts of text from those RFCs.  If you can contact all
    authors of the source material and they are willing to grant the BCP78
    rights to the IETF Trust, you can and should remove the disclaimer.
    Otherwise, the disclaimer is needed and you can ignore this comment.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

[Ballot comment]
Considering that
1. BMP will simply transmit the PDU
2. The use cases is monitoring
3. The correlation between BMP and draft-ietf-idr-bgp-model is possible (at least manually)
4. It's implemented today
I'll remove my DISCUSS


COMMENT:
- From the write-up:

-- The BMP protocol has been a GROW document for quite sometime.  The
-- length of time has allowed the document to have multiple implementations
-- completed, along with incorporating working group feedback into the spec
-- and polishing the document.

Btw, don't forget, for future documents, the experimental RFC 6982 "Improving Awareness of Running Code: The Implementation Status Section"

-  following nits need to be addressed in the document.

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to contain a disclaimer for pre-RFC5378 work, but was
    first submitted on or after 10 November 2008.  The disclaimer is usually
    necessary only for documents that revise or obsolete older RFCs, and that
    take significant amounts of text from those RFCs.  If you can contact all
    authors of the source material and they are willing to grant the BCP78
    rights to the IETF Trust, you can and should remove the disclaimer.
    Otherwise, the disclaimer is needed and you can ignore this comment.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: draft-ietf-idr-error-handling has been published as
    RFC 7606

[Ballot discuss]
This DISCUSS is in line with Mahesh's OPS DIR review.
If BMP (which I consider like a span port feature btw) troubleshooting shows that the BGP configuration is required, then the standard way to configure BGP will be https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00.
I'm wondering about the link between BMP and the following draft-ietf-idr-bgp-model-00.txt YANG models:

bgp-types.yang
bgp-policy.yang
bgp-multiprotocol.yang
bgp.yang
bgp-operational.yang

Specifically: are we able to map the Per-Peer Header (section 4.2) and Information TLV (section 4.4) to draft-ietf-idr-bgp-model-00.txt.  Either because the field information come from the same reference (ex: both this draft and the idr one have the same reference for the Peer Distinguisher), or because specific references to the YANG key information is provided.
I believe that the draft-ietf-grow-bmp and draft-ietf-idr-bgp-model authors should sit down and go through the exercise of mapping the BMP data model into the YANG data model, for a couple of troubleshooting scenarios. The OPS world suffers from too many different data models (MIB, IPFIX, YANG, etc.). With this DISCUSS, I want to make sure that we won't fall into the trap of defining a new one without at least providing the necessary mappings. Note: I see that sysName and sysDescr make the link with the MIB world, that's a step in the right direction.


Below is Mahesh's OPS DIR review:

Summary:
This document defines a protocol, BMP, that can be used to monitor BGP sessions.  BMP is intended to provide a convenient interface for obtaining route views.  Prior to introduction of BMP, screen-scraping was the most commonly-used approach to obtaining such views.  The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting.  BMP is not suitable for use as a routing protocol.

The document is on standards track and defines another monitoring method specifically for BGP. The original draft is dated 2005, long before NETCONF or YANG were defined, and when there was probably no way to view routes. With the advent of NETCONF and specifically the BGP YANG model, which is currently a WG document, it would be helpful to know how BMP stands apart. The NETCONF notification structure allows for notifications described in this draft and the ability to collect stats reports and route monitoring. It would be helpful to know how BMP compliments that capability.

[Ballot comment]
COMMENT:
- From the write-up:

-- The BMP protocol has been a GROW document for quite sometime.  The
-- length of time has allowed the document to have multiple implementations
-- completed, along with incorporating working group feedback into the spec
-- and polishing the document.

Btw, don't forget, for future documents, the experimental RFC 6982 "Improving Awareness of Running Code: The Implementation Status Section"

-  following nits need to be addressed in the document.

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to contain a disclaimer for pre-RFC5378 work, but was
    first submitted on or after 10 November 2008.  The disclaimer is usually
    necessary only for documents that revise or obsolete older RFCs, and that
    take significant amounts of text from those RFCs.  If you can contact all
    authors of the source material and they are willing to grant the BCP78
    rights to the IETF Trust, you can and should remove the disclaimer.
    Otherwise, the disclaimer is needed and you can ignore this comment.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: draft-ietf-idr-error-handling has been published as
    RFC 7606

[Ballot comment]
I support Stephen's and Kathleen's discuss positions concerning the lack of MTI security. I'm balloting no-objection (for now) so that those conversations can happen on their respective threads.

3.2:
The says no message is ever sent by the monitoring station, but the last paragraph in the section mentions a monitoring station sending a termination message. Also, does the strategy for retrying failed connection attempts apply to reconnects after the fail or an existing connection?

The 3rd paragraph from the end talks about redundant connections happening when both parties are configured as active. But previous paragraphs suggested that only passive endpoints will listen for a connection. How could this result in redundant connections? Is there logic to make sure the endpoints do not terminate both redundant connections?

IANA Considerations:

Several of the tables reserve an experimental range of 65531 through 65534. Is it really the intent to have experimental ranges with only 4 code-points each?

[Ballot comment]
Thank you for a clear and well-written document.  This was easy to read and understand.
I do have a couple questions.

a) In Section 4.2, I see special casing for an "L3VPN Instance Peer".  Will the same thing be necessary for an EVPN peer?  Are there other future cases to be considered?

b) In Sec 4.4, for the type=0 String, it may be useful to specify that the language is unspecified and based on the configuration.  A similar description for the other information strings would be useful.  I'm sure that Barry could suggest better text.

[Ballot discuss]

Apologies in advance for the rant, but this is a new
protocol and not something deployed for decades that can't
be fixed. (At least so says the write-up.)

The state of security here is just sad. It reminds me of the
1980's. And introducing new protocols without improving that
goes against very long held IETF consensus that protocols
need to have some actually usable strong security mechanism
defined.  It seems the wg here get that but are choosing to
do nothing about it - I mean in their day-jobs, not that
writing RFC text is "doing something." The responses to the
secdir review seem to make it clear that the claim that
IPsec can be used is mythical, so this discuss to ask that
the security considerations properly document the utter
absence of any modern way to secure this protocol and not
pretend that there are ways that can be used to secure this
in the real world. I would suggest text that simply says
that:

"This is an inherently insecure protocol for no particularly
good reason and mostly due to the lack of implementation of
basic security mechanisms (SSH, TLS) but also due to a lack
of customer/operator pressure to ensure those are present,
usable and interoperate, despite evidence that attacks on
the links over which this data will be sent are ongoing."

I'd not be surprised if you preferred some other text:-)

[Ballot comment]

Separate to the discuss, I have some non-blocking points,
that I think resonate with Kathleen's discuss:

Why is using TLS not a no-brainer for this?  Given the likes
of the Belgacom and Gemalto reports, I would love to
understand why people are still willing to buy and sell
equipment without such basic features. The "explanation"
that nobody needs it or nobody provides it seems off base
here - this is new code and a new interface, and the
relevant security protocols (SSH, IPsec and TLS) are all
nearly or more than 20 years old. And that is all the more
the case for a new protocol like this that is not likely in
the critical path and where the monitoring statiion may be
off to the side so the traffic flows via BMP in places where
BGP doesn't go implying different threat levels, that may
need different protection.

My best guess as to causes for now is that people are just
used to doing nothing and have done that for so long they
seem to think that doing nothing is the only possibility.
(That's how business models get disrupted isn't it?) Can you
educate me some more on this?

(And yes, I get that all the stuff as to why AO isn't
available for BGP, but this is not BGP. It's our apparent
need to keep the security level down at the "crap" marker
that I don't get.)

[Ballot comment]
I found myself wondering when you can start route mirroring, and whether there was any guidance about what to do when a BGP speaker runs out of buffers so that route mirroring is no longer complete.

[Ballot discuss]
The statements on authenticated access and confidentiality are helpful, but this is a new protocol and should not start out with the security property levels of the current BGP deployments.  Efforts have been made to publish RFCs to fix BGP security and the vulnerabilities have been published - even in the Washington Post.  I'd like to see more security required for the properties mentioned to prevent active and passive attacks getting dumps of the BGP data, which was not previously available.  If this is not possible per the suggestions below, please explain why.  If there is a good reason, it would be helpful to remove the text that says its okay to leave security out because BGP isn't secure and just include the security considerations.

Now for specifics:

1. In the Security considerations, it is not only a passive attacker, but also an active one that could gain access to the session if it is not encrypted (protected for confidentiality).  An active attacker might change routes causing network disruption.  A passive attacker might better understand the possible paths to an AS, assisting with a more effective DDoS attack.  The latter point is important to consider in the first paragraph of this section that currently says,
  "although it's hard to consider the content of BGP routes in the
  public Internet to be confidential,"

I think this is a bit of an overstatement as the exact routes and paths are not published for each router and could be used for DoS attacks - for example taking out one or more paths to a network AS.

What I am suggesting for #1 is a simple text change to address the fuller set of security considerations.
Change from:
  Unless a transport that provides confidentiality is used,
  a passive attacker could gain access to BMP data in flight.
To:
  Unless a transport that provides confidentiality is used,
  a passive or active attacker could gain access to or tamper the BMP data in flight.


2. The last paragraph would be the right place to require session encryption and authentication for sessions (unless there is a good explanation as to why this is not needed).  If the transport may vary, then it's okay to leave IPsec as a suggestion.  It would be nice if there was an MTI for transport, so the security protections could be consistent and interoperability would be easier between implementations.  This also came up in the SecDir review.
https://www.ietf.org/mail-archive/web/secdir/current/msg06011.html
In any case, it would be good to discuss this and see if there are good reasons to leave it as-is or to change the text to improve security, preventing a few attack types.

[Ballot comment]
The shepherd write-up says that IPR was declared, but the datatracker shows nothing for this draft or its predecessor.

===
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

-- Yes.
===

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-grow-bmp-15.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, IANA understands that there are eight actions which IANA must complete.

IANA understands that this document requests the creation of eight new registries. The new registries are to be grouped into a common, master registry on the IANA Protocol Registry matrix at:

https://www.iana.org/protocols

The new, master registry is to be called, "BGP Monitoring Protocol (BMP) Parameters" with a reference of [ RFC-to-be ].

First, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the BMP Message Types registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Type values 0 through 128 MUST be assigned using the "Standards Action" policy, and values 129 through 250 using the "Specification Required" policy defined in [RFC5226]. Values 251 through 254 are "Experimental" and value 255 is reserved.

There are initial registrations in the new subregistry as follows:

Type Description Reference
-------+--------------------------------+------------------
0 Route Monitoring [ RFC-to-be ]
1 Statistics Report [ RFC-to-be ]
2 Peer Down Notification [ RFC-to-be ]
3 Peer Up notification [ RFC-to-be ]
4 Initiation [ RFC-to-be ]
5 Termination [ RFC-to-be ]
6 Route Mirroring [ RFC-to-be ]
7-250 Unassigned
251-254 Experimental
255 Reserved

Second, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the BMP Statistics Types registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Statistic Type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are "Experimental" and value 65535 is reserved.

There are initial registrations in the new subregistry as follows:

Stat
Type Description Reference
-----+--------------------------------------------------+----------------
0 Number of prefixes rejected by inbound policy. [ RFC-to-be ]
1 Number of (known) duplicate prefix advertisements. [ RFC-to-be ]
2 Number of (known) duplicate withdraws. [ RFC-to-be ]
3 Number of updates invalidated due to CLUSTER_LIST [ RFC-to-be ]
loop.
4 Number of updates invalidated due to AS_PATH loop. [ RFC-to-be ]
5 Number of updates invalidated due to ORIGINATOR_ID.[ RFC-to-be ]
6 Number of updates invalidated due to a loop found [ RFC-to-be ]
in AS_CONFED_SEQUENCE or AS_CONFED_SET.
7 Number of routes in Adj-RIBs-In. [ RFC-to-be ]
8 Number of routes in Loc-RIB. [ RFC-to-be ]
9 Number of routes in per-AFI/SAFI Adj-RIB-In. [ RFC-to-be ]
10 Number of routes in per-AFI/SAFI Loc-RIB. [ RFC-to-be ]
11 Number of updates subjected to treat-as-withdraw. [ RFC-to-be ]
12 Number of prefixes subjected to treat-as-withdraw. [ RFC-to-be ]
13 Number of duplicate update messages received. [ RFC-to-be ]
14-65530 Unassigned
65531-65524 Experimental Use
65535 Reserved

Third, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the BMP Initiation Message TLVs registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Initiation type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are "Experimental" and value 65535 is reserved.

There are initial registrations in the new subregistry as follows:

Type Description Reference
-------+---------------------+----------------
0 String [ RFC-to-be ]
1 sysDescr [ RFC-to-be ]
2 sysName [ RFC-to-be ]
3-65530 Unassigned
65531-65534 Experimental Use
65535 Reserved

Fourth, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the BMP Termination Message TLVs registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Termanation type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are "Experimental" and value 65535 is reserved.

There are initial registrations in the new subregistry as follows:

Type Description Reference
-------+---------------------+----------------
0 String [ RFC-to-be ]
1 Reason [ RFC-to-be ]
2-65530 Unassigned
65531-65534 Experimental Use
65535 Reserved

Fifth, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the BMP Termination Message Reason Codes registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Reason code values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are "Experimental" and value 65535 is reserved.

There are initial registrations in the new subregistry as follows:

Type Description Reference
-------+------------------------------------+----------------
0 Administratively closed [ RFC-to-be ]
1 Unspecified reason [ RFC-to-be ]
2 Out of resources [ RFC-to-be ]
3 Redundant connection [ RFC-to-be ]
4 Permanently administratively closed [ RFC-to-be ]
5-65530 Unassigned
65531-65534 Experimental Use
65535 Reserved

Sixth, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the BMP Peer Down Reason Codes registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Reason code values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are "Experimental" and values 0 and 65535 are reserved

There are initial registrations in the new subregistry as follows:

Type Description Reference
-------+-----------------------------------------------+----------------
0 Reserved [ RFC-to-be ]
1 Local system closed, NOTIFICATION PDU follows. [ RFC-to-be ]
2 Local system closed, FSM Event follows. [ RFC-to-be ]
3 Remote system closed, NOTIFICATION PDU follows. [ RFC-to-be ]
4 Remote system closed, no data. [ RFC-to-be ]
5 Peer de-configured. [ RFC-to-be ]
6-65530 Unassigned
65531-65534 Experimental Use
65535 Reserved

Seventh, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the Route Mirroring TLVs registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Route mirroring TLV values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are "Experimental" and value 65535 is reserved.

There are initial registrations in the new subregistry as follows:

Type Description Reference
-------+---------------------+----------------
0 BGP Message [ RFC-to-be ]
1 Information [ RFC-to-be ]
2-65530 Unassigned
65531-65534 Experimental Use
65535 Reserved

Eighth, a new subregistry of the new BGP Monitoring Protocol (BMP) Parameters registry created above is to be created. It will be called the BMP Route Mirroring Information Codes registry. The maintenance policy [as defined in RFC 5226] for the new registry is as follows:

Information code values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are "Experimental" and value 65535 is reserved.

There are initial registrations in the new subregistry as follows:

Type Description Reference
-------+---------------------+----------------
0 Errored PDU [ RFC-to-be ]
1 Messages Lost [ RFC-to-be ]
2-65530 Unassigned
65531-65534 Experimental Use
65535 Reserved

IANA understands that these eight actions are the only ones required to be completed upon approval of this document.


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Michelle Cotton
Protocol Parameters Engagement Manager
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGP Monitoring Protocol) to Proposed Standard


The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'BGP Monitoring Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a protocol, BMP, that can be used to monitor
  BGP sessions.  BMP is intended to provide a convenient interface for
  obtaining route views.  Prior to introduction of BMP, screen-scraping
  was the most commonly-used approach to obtaining such views.  The
  design goals are to keep BMP simple, useful, easily implemented, and
  minimally service-affecting.  BMP is not suitable for use as a
  routing protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/ballot/


No IPR declarations have been submitted directly on this I-D.