Skip to main content

Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
draft-ietf-grow-bmp-adj-rib-out-07

Revision differences

Document history

Date Rev. By Action
2019-11-04
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-11-04
Jenny Bui Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-grow-bmp-adj-rib-out
2019-10-14
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-09-25
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-09-03
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-08-30
07 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2019-08-29
07 (System) IANA Action state changed to Waiting on Authors
2019-08-27
07 (System) RFC Editor state changed to EDIT
2019-08-27
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-08-27
07 (System) Announcement was received by RFC Editor
2019-08-26
07 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Jouni Korhonen was marked no-response
2019-08-26
07 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-08-26
07 Amy Vezza IESG has approved the document
2019-08-26
07 Amy Vezza Closed "Approve" ballot
2019-08-26
07 Amy Vezza Ballot approval text was generated
2019-08-26
07 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-08-15
07 Benjamin Kaduk
[Ballot comment]
Thank you for the discussion about my Discuss point; it seems that
the document will probably be clear enough to the intended audience …
[Ballot comment]
Thank you for the discussion about my Discuss point; it seems that
the document will probably be clear enough to the intended audience
that I do not need to press the point further, even if it remains somewhat
unclear to readers in a broader audience.

Section 1

                      An example of pre-policy verses post-policy is
  when an inbound policy applies attribute modification or filters.
  Pre-policy would contain information prior to the inbound policy
  changes or filters of data.  Post policy would convey the changed
  data or would not contain the filtered data.

I think we had some discussion relating to my question about policy
being used to inject new data, and even some suggested edits from Jeff,
but I couldn't find those in the -07.  Perhaps I just missed them, though.Section 8

Section 8

I agree with the conclusion from discussions on Alvaro's point, that implementations
SHOULD only use this with trusted/authorized monitoring devices.  But I think it's
the role of the security considerations to clarify why this is the case (i.e., that new
information would be made available otherwise), and not just provide a rule to be
blindly adhered to.
2019-08-15
07 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-08-05
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-08-05
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-08-05
07 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-07.txt
2019-08-05
07 (System) New version approved
2019-08-05
07 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Shunwan Zhuang , Kevin Mi , Paolo Lucente , Tim Evens
2019-08-05
07 Tim Evens Uploaded new revision
2019-08-02
06 Catherine Meadows Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Catherine Meadows. Sent review to list.
2019-07-17
06 Barry Leiba
[Ballot comment]
Thanks for addressing my comments!

Two former DISCUSS points that have been addressed in the working version in github:

— Section 4 — …
[Ballot comment]
Thanks for addressing my comments!

Two former DISCUSS points that have been addressed in the working version in github:

— Section 4 —

  The existing flags are defined in section 4.2 [RFC7854] and the
  remaining bits are reserved for future use.  They SHOULD be
  transmitted as 0 and their values MUST be ignored on receipt.

Why “SHOULD”?  That’s inconsistent with Section 4.2 of 7854, which says “MUST”.  Failing to set the reserved bits to 0 will cause interoperability problems with future extensions.

  The following fields in the Per-Peer Header are redefined:

You aren’t redefining them completely, right?  Don’t you mean, “When the O flag is set to 1, the following fields in the Per-Peer Header are redefined:” ?

---

And some editorial comments, also addressed in github:

Throughout: there are five instances of “use-case”.  “Use case” should not be hyphenated (unless it’s used as a modifier, which it isn’t here).

— Section 1 —

  An example of pre-policy verses post-policy is

You mean “versus”, with a “u” (and also a second time later in the section).

  This document updates section
  4.2 [RFC7854] per-peer header by adding a new flag

That’s an odd way to do the citation.  Also, “per-peer header” is misplaced:

NEW
This document updates the per-peer header in section 4.2 of [RFC7854] by adding a new flag
END

The other places in the document that say “section 4.2 [RFC7854]” should also be changed to “section 4.2 of [RFC7854]”.

— Section 6.3.1 —

      The Information field contains a free-form
      UTF-8 string whose length is given by the Information Length
      field.

As one UTF-8 character can be more than one byte, it’s best to specify whether the length is in bytes or characters.  I would say, “whose byte length is given....” (also in Section 9.3)

— Section 9.3 —
The sentence, “The value is administratively given by the Information Length field.” appears to be a copy/paste error, and should be deleted.
2019-07-17
06 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2019-07-11
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-07-11
06 Ignas Bagdonas [Ballot comment]
Thank you for this work - the industry needs it.

A nit: s/ template-based/template
2019-07-11
06 Ignas Bagdonas [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas
2019-07-10
06 Roman Danyliw
[Ballot comment]
I support Ben’s DISCUSS about the Peer Down and Up Notification (i.e., Section 6.3).

Section 8, I also share Alvaro’s and Ben’s concern …
[Ballot comment]
I support Ben’s DISCUSS about the Peer Down and Up Notification (i.e., Section 6.3).

Section 8, I also share Alvaro’s and Ben’s concern about whether any new information is leaked if pre- and post-policy information is combined
2019-07-10
06 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-07-10
06 Adam Roach [Ballot comment]
I support Barry's discuss points.
2019-07-10
06 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-07-10
06 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-07-10
06 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-07-09
06 Barry Leiba
[Ballot discuss]
Two small points that will be trivial to address:

— Section 4 —

  The existing flags are defined in section 4.2 [ …
[Ballot discuss]
Two small points that will be trivial to address:

— Section 4 —

  The existing flags are defined in section 4.2 [RFC7854] and the
  remaining bits are reserved for future use.  They SHOULD be
  transmitted as 0 and their values MUST be ignored on receipt.

Why “SHOULD”?  That’s inconsistent with Section 4.2 of 7854, which says “MUST”.  Failing to set the reserved bits to 0 will cause interoperability problems with future extensions.

  The following fields in the Per-Peer Header are redefined:

You aren’t redefining them completely, right?  Don’t you mean, “When the O flag is set to 1, the following fields in the Per-Peer Header are redefined:” ?
2019-07-09
06 Barry Leiba
[Ballot comment]
Some editorial comments:

Throughout: there are five instances of “use-case”.  “Use case” should not be hyphenated (unless it’s used as a modifier, which …
[Ballot comment]
Some editorial comments:

Throughout: there are five instances of “use-case”.  “Use case” should not be hyphenated (unless it’s used as a modifier, which it isn’t here).

— Section 1 —

  An example of pre-policy verses post-policy is

You mean “versus”, with a “u” (and also a second time later in the section).

  This document updates section
  4.2 [RFC7854] per-peer header by adding a new flag

That’s an odd way to do the citation.  Also, “per-peer header” is misplaced:

NEW
This document updates the per-peer header in section 4.2 of [RFC7854] by adding a new flag
END

The other places in the document that say “section 4.2 [RFC7854]” should also be changed to “section 4.2 of [RFC7854]”.

— Section 6.3.1 —

      The Information field contains a free-form
      UTF-8 string whose length is given by the Information Length
      field.

As one UTF-8 character can be more than one byte, it’s best to specify whether the length is in bytes or characters.  I would say, “whose byte length is given....” (also in Section 9.3)

— Section 9.3 —
The sentence, “The value is administratively given by the Information Length field.” appears to be a copy/paste error, and should be deleted.
2019-07-09
06 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2019-07-09
06 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-07-09
06 Martin Vigoureux
[Ballot comment]
Hello,

Somehow related to Benjamin's comment, I'm not sure how to interpret this change:

  The following fields in the Per-Peer Header are …
[Ballot comment]
Hello,

Somehow related to Benjamin's comment, I'm not sure how to interpret this change:

  The following fields in the Per-Peer Header are redefined:

  o  Peer Address: The remote IP address associated with the TCP
      session over which the encapsulated PDU is sent.

  o  Peer AS: The Autonomous System number of the peer from which the
      encapsulated PDU was sent.

  o  Peer BGP ID: The BGP Identifier of the peer from which the
      encapsulated PDU was sent.

In which context are these new definitions valid? i.e., for O=1 only? Whatever the answer I think it wouldn't hurt to make that clear.

Also, I read that a requirement has changed:
in rfc7854
    *  The remaining bits are reserved for future use.  They MUST be
        transmitted as 0 and their values MUST be ignored on receipt.
in your draft
  The existing flags are defined in section 4.2 [RFC7854] and the
  remaining bits are reserved for future use.  They SHOULD be
  transmitted as 0 and their values MUST be ignored on receipt.

Is that intentional?

Finally:
  o  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
      an Adj-RIB-Out. This MUST be what is actually sent to the peer.
Maybe I'm reading incorrectly the last sentence but I'm under the impression that setting such requirement is outside the scope of this document. Shouldn't it rather say: "This is what is actually sent to the peer."
2019-07-09
06 Martin Vigoureux Ballot comment text updated for Martin Vigoureux
2019-07-09
06 Martin Vigoureux
[Ballot comment]
I wondered whether that should be a DISCUSS or a COMMENT. I've chosen the latter.

Somehow related to Benjamin's comment, I'm not sure …
[Ballot comment]
I wondered whether that should be a DISCUSS or a COMMENT. I've chosen the latter.

Somehow related to Benjamin's comment, I'm not sure how to interpret this change:

  The following fields in the Per-Peer Header are redefined:

  o  Peer Address: The remote IP address associated with the TCP
      session over which the encapsulated PDU is sent.

  o  Peer AS: The Autonomous System number of the peer from which the
      encapsulated PDU was sent.

  o  Peer BGP ID: The BGP Identifier of the peer from which the
      encapsulated PDU was sent.

In which context are these new definitions valid? i.e., for O=1 only? Whatever the answer I think it wouldn't hurt to make that clear.

Also, I read that a requirement has changed:
in rfc7854
    *  The remaining bits are reserved for future use.  They MUST be
        transmitted as 0 and their values MUST be ignored on receipt.
in your draft
  The existing flags are defined in section 4.2 [RFC7854] and the
  remaining bits are reserved for future use.  They SHOULD be
  transmitted as 0 and their values MUST be ignored on receipt.

Is that intentional?

Finally:
  o  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
      an Adj-RIB-Out. This MUST be what is actually sent to the peer.
Maybe I'm reading incorrectly the last sentence but I'm under the impression that setting such requirement is outside the scope of this document. Shouldn't it rather say: "This is what is actually sent to the peer."
2019-07-09
06 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-07-08
06 Benjamin Kaduk
[Ballot discuss]
The "Peer Up message Information" TLV type seems under-specified and
under-motivated.  (It is not mentioned in Abstract or Introduction.)  Why
does it need …
[Ballot discuss]
The "Peer Up message Information" TLV type seems under-specified and
under-motivated.  (It is not mentioned in Abstract or Introduction.)  Why
does it need to be defined in this document, and what role is it
expected to play?  Who is the expected audience for it?  Is it limited
to the "group name"-like functionality described in Section 7.1?  Why is
cleartext appropriate, and are there any potential privacy
considerations for any potential use cases?
2019-07-08
06 Benjamin Kaduk
[Ballot comment]
Section 1

                      An example of pre-policy verses post-policy is
  when an …
[Ballot comment]
Section 1

                      An example of pre-policy verses post-policy is
  when an inbound policy applies attribute modification or filters.
  Pre-policy would contain information prior to the inbound policy
  changes or filters of data.  Post policy would convey the changed
  data or would not contain the filtered data.

Can applying policy ever act as injecting new data?

Separately, I'd ask whether it's worth mentioning the new statistics
types in the Introduction (skipping them from the Abstract is probably
understandable).

Section 4

  o  Peer Address: The remote IP address associated with the TCP
      session over which the encapsulated PDU is sent.

  o  Peer AS: The Autonomous System number of the peer from which the
      encapsulated PDU was sent.

  o  Peer BGP ID: The BGP Identifier of the peer from which the
      encapsulated PDU was sent.

I am not sure whether I'm reading these properly.  Backing up, in
regular RFC 7854 BMP, we have a BMP sender (router) that is speaking BGP
to (presumably many) peers.  These Peer Address/AS/BGP-ID fields are
attributes of the BGP connections the router has to its peers, and are
talking about how the data is coming in.  For the Adj-RIB-Out version
that we're defining in this document, we want to flip the sense, so that
we are talking about what the router is sending on its outgoing BGP
connections.  In this way, the content being sent over BMP still
reflects the origin of the BGP data, which makes sense.  What's tripping
me up is that we still talk about "the peer from which the encapsulated
PDU was sent" -- IIUC this is "peer" in the "BGP peering" sense, so the
data being sent over BMP is the local data from the router.  Do we need
to say "peer" at all, here, then?  So, "The AS number for which the
encapsulated PDU was sent", and "The BGP Identifier for which the
encapsulated PDU was sent"?

  o  Timestamp: The time when the encapsulated routes were advertised
      (one may also think of this as the time when they were installed
      in the Adj-RIB-Out), expressed in seconds and microseconds since
      midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
      unavailable.  Precision of the timestamp is implementation-
      dependent.

Are leap seconds included in this value?  (Yes, I see that this language
is basically taken directly from RFC 7854, which also left it
underspecified.)

Section 5.1

                                                              Some
  attributes are set when the BGP message is transmitted, such as next-
  hop.  Adj-RIB-Out Post-Policy MUST convey what is actually
  transmitted to the peer, next-hop and any attributes set during
  transmission should also be set and transmitted to the BMP receiver.

I'm having a bit of trouble matching up "MUST convey" with "should also
be set".  (Also, we seem to say "MUST be what is actually sent to the
peer" in Section 3; do we need the normative language in both places?)
nit: this is a comma splice

Section 5.2

  Some attributes are set only during transmission of the BGP message,
  i.e., Post-Policy.  It is common that next-hop may be null, loopback,
  or similar during this phase.  All mandatory attributes, such as

nit: I suggest clarifying that "this phase" is pre-policy, not "during
transmission".

Section 6.2

Do we need to say anything about the byte order of the 2- and 8-byte
fields in these statistics structures?

Section 6.3

                          BMP receiver implementations SHOULD ignore the
  O flag in Peer Up and Down notifications.  BMP receiver
  implementations MUST use the per-peer header O flag in route
  monitoring and mirroring messages to identify if the message is for
  Adj-RIB-In or Adj-RIB-Out.

Is this last MUST duplicating content elsewhere in the document?  It
doesn't seem related to the title of the section, "peer down and up
notifications".

Section 7.1

Do I interpret this correctly as saying that peer and update groups are
not a defined protocol feature but rather something offered by
implementations for convenience of administrators?  The language about
"should be simple to include a group name [...] but it is more complex
than that" leaves me a little confuesd about what is current deployed
reality, what is speculation about potential future work, and what is
being defined as an actual new protocol feature.

Section 8

The administrative information TLV has some considerations about what
kind of internal organizational information is shared to "the world".

As Alvaro notes, publishing both pre- and post-policy outbound RIBs can
give a new information channel into what the policy applied to outbound
routes is, and presumably the usual BMP configuration considerations
apply about only sending information to people authorized to receive it.

Section 9.3

The registry where this seems to be listed claims to be the "BMP
Initiation Message TLVs" registry; is the section heading of "Peer Up
Information TLV" appropriate?
2019-07-08
06 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-07-08
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-07-08
06 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-07-03
06 Alvaro Retana
[Ballot comment]
I am balloting Yes because I think this is important and needed work.

However, I think the Security Considerations section is incomplete.  Right …
[Ballot comment]
I am balloting Yes because I think this is important and needed work.

However, I think the Security Considerations section is incomplete.  Right now it just says: "It is not believed that this document adds any additional security considerations."

The text should at least point to the Security Considerations from rfc7854.

In §5.2, this example is offered: "a comparison between pre-policy and post-policy can be used to validate the outbound policy".  While validation is the expected use case, it would be relatively simple to reconstruct the outbound policy itself.  This fact means that the new functionality allows BMP receivers to learn information about the monitored peer that otherwise would not be available, which may result in loss of privacy, the ability to craft a route to bypass specific policy, etc..  The point that I'm making here goes beyond gaining unauthorized access to BMP data (which is mentioned in rfc7854), to the potential ability to figure out policy and then craft attacks based on that knowledge.  The mitigation is of course to establish these sessions with authorized *and* trusted peers.
2019-07-03
06 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2019-07-02
06 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-06-27
06 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-06-27
06 Amy Vezza Placed on agenda for telechat - 2019-07-11
2019-06-27
06 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup
2019-06-27
06 Warren Kumari Ballot has been issued
2019-06-27
06 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2019-06-27
06 Warren Kumari Created "Approve" ballot
2019-06-27
06 Warren Kumari Ballot writeup was changed
2019-06-25
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-06-23
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-06-23
06 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-06.txt
2019-06-23
06 (System) New version approved
2019-06-23
06 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Shunwan Zhuang , Kevin Mi , Paolo Lucente , Tim Evens
2019-06-23
06 Tim Evens Uploaded new revision
2019-06-22
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2019-06-22
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2019-06-20
05 Min Ye Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Acee Lindem.
2019-06-19
05 Min Ye Closed request for Last Call review by RTGDIR with state 'Overtaken by Events'
2019-06-19
05 Min Ye Request for Last Call review by RTGDIR is assigned to Acee Lindem
2019-06-19
05 Min Ye Request for Last Call review by RTGDIR is assigned to Acee Lindem
2019-06-19
05 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-06-19
05 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-grow-bmp-adj-rib-out-05. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-grow-bmp-adj-rib-out-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the BMP Peer Flags on the BGP Monitoring Protocol (BMP) Parameters registry page located at:

https://www.iana.org/assignments/bmp-parameters/

The temporary registration for Flag 3 - the O flag will be made permanent and its reference changed to [ RFC-to-be ].

Second, in the BMP Statistics Types registry also on the BGP Monitoring Protocol (BMP) Parameters registry page located at:

https://www.iana.org/assignments/bmp-parameters/

Four temporary registrations will be made permanent and their references changed to [ RFC-to-be ]:

Stat Type = 14: Number of routes in Adj-RIBs-Out Pre-Policy
Stat Type = 15: Number of routes in Adj-RIBs-Out Post-Policy
Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- Policy
Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- Policy

Third, in the BMP Initiation Message TLVs registry also on the BGP Monitoring Protocol (BMP) Parameters registry page located at:

https://www.iana.org/assignments/bmp-parameters/

the temporary registration for Type 4 - Admin label will be made permanent and its reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-06-14
05 Linda Dunbar Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Linda Dunbar. Sent review to list.
2019-06-13
05 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2019-06-13
05 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2019-06-12
05 Alvaro Retana Requested Last Call review by RTGDIR
2019-06-12
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2019-06-12
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2019-06-11
05 Alvaro Retana Requested Last Call review by RTGDIR
2019-06-11
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-06-11
05 Amy Vezza
The following Last Call announcement was sent out (ends 2019-06-25):

From: The IESG
To: IETF-Announce
CC: grow-chairs@ietf.org, grow@ietf.org, morrowc@ops-netman.net, Chris Morrow , …
The following Last Call announcement was sent out (ends 2019-06-25):

From: The IESG
To: IETF-Announce
CC: grow-chairs@ietf.org, grow@ietf.org, morrowc@ops-netman.net, Chris Morrow , draft-ietf-grow-bmp-adj-rib-out@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)) to Proposed Standard


The IESG has received a request from the Global Routing Operations WG (grow)
to consider the following document: - 'Support for Adj-RIB-Out in BGP
Monitoring Protocol (BMP)'
  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 2019-06-25. 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


  The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
  In Routing Information Bases (RIBs).  This document updates the BGP
  Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
  Out RIBs.  It adds a new flag to the peer header to distinguish Adj-
  RIB-In and Adj-RIB-Out.




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

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


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




2019-06-11
05 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-06-11
05 Warren Kumari Last call was requested
2019-06-11
05 Warren Kumari Last call announcement was generated
2019-06-11
05 Warren Kumari Ballot approval text was generated
2019-06-11
05 Warren Kumari Ballot writeup was generated
2019-06-11
05 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2019-06-07
05 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-05.txt
2019-06-07
05 (System) New version approved
2019-06-07
05 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Shunwan Zhuang , Kevin Mi , Paolo Lucente , Tim Evens
2019-06-07
05 Tim Evens Uploaded new revision
2019-05-30
04 Warren Kumari
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard
[Edit: WK] This document updates (Standards Track) RFC7854 and also makes assignment from the "Standards Action" BGP Monitoring Protocol (BMP) Parameters registry.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

"The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
  In Routing Information Bases (RIBs).  This document updates the BGP
  Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
  Out RIBs.  It adds a new flag to the peer header to distinguish Adj-
  RIB-In and Adj-RIB-Out."

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document went through several revisions and extensive review at WGLC to include comments/suggestions/changes.
The conversation in the WG mail-list and meetings was robust.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is in good shape, there are no nits of consequence in the document.
The content is clear an concise.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: chris morrow (morrowc@ops-netman.net)
Responsible AD: warren kumari (warren@kumari.net)


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has read the document more than 1 time.
I believe the document is ready for publication at this time.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

no portions of the document are in need of review beyond that which the editor(s) have already provided.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR confirmation received, no IPR outstanding.

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

yes, no disclosures required.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

NO

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The only nit appears to be a formatting choice on the 'URI's section of the document.
This doesn't appear to be a real nit.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no formal reviews are reqiured.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

no

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

it will not.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA is requested to assign a new BMP Parameter from an existing registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

none

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

id-nits run.
2019-05-22
04 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

"The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
  In Routing Information Bases (RIBs).  This document updates the BGP
  Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
  Out RIBs.  It adds a new flag to the peer header to distinguish Adj-
  RIB-In and Adj-RIB-Out."

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document went through several revisions and extensive review at WGLC to include comments/suggestions/changes.
The conversation in the WG mail-list and meetings was robust.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is in good shape, there are no nits of consequence in the document.
The content is clear an concise.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: chris morrow (morrowc@ops-netman.net)
Responsible AD: warren kumari (warren@kumari.net)


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has read the document more than 1 time.
I believe the document is ready for publication at this time.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

no portions of the document are in need of review beyond that which the editor(s) have already provided.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR confirmation received, no IPR outstanding.

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

yes, no disclosures required.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

NO

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The only nit appears to be a formatting choice on the 'URI's section of the document.
This doesn't appear to be a real nit.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no formal reviews are reqiured.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

no

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

it will not.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA is requested to assign a new BMP Parameter from an existing registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

none

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

id-nits run.
2019-05-22
04 Chris Morrow Responsible AD changed to Warren Kumari
2019-05-22
04 Chris Morrow IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2019-05-22
04 Chris Morrow IESG state changed to Publication Requested from I-D Exists
2019-05-22
04 Chris Morrow IESG process started in state Publication Requested
2019-05-22
04 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

"The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
  In Routing Information Bases (RIBs).  This document updates the BGP
  Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
  Out RIBs.  It adds a new flag to the peer header to distinguish Adj-
  RIB-In and Adj-RIB-Out."

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document went through several revisions and extensive review at WGLC to include comments/suggestions/changes.
The conversation in the WG mail-list and meetings was robust.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is in good shape, there are no nits of consequence in the document.
The content is clear an concise.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: chris morrow (morrowc@ops-netman.net)
Responsible AD: warren kumari (warren@kumari.net)


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has read the document more than 1 time.
I believe the document is ready for publication at this time.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

no portions of the document are in need of review beyond that which the editor(s) have already provided.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR confirmation received, no IPR outstanding.

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

yes, no disclosures required.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

NO

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The only nit appears to be a formatting choice on the 'URI's section of the document.
This doesn't appear to be a real nit.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no formal reviews are reqiured.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

no

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

it will not.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA is requested to assign a new BMP Parameter from an existing registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

none

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

id-nits run.
2019-05-22
04 Chris Morrow Notification list changed to Chris Morrow <morrowc@ops-netman.net>
2019-05-22
04 Chris Morrow Document shepherd changed to Chris Morrow
2019-03-24
04 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-04.txt
2019-03-24
04 (System) New version approved
2019-03-24
04 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Shunwan Zhuang , Kevin Mi , Paolo Lucente , Tim Evens
2019-03-24
04 Tim Evens Uploaded new revision
2018-12-19
03 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-03.txt
2018-12-19
03 (System) New version approved
2018-12-19
03 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Shunwan Zhuang , Kevin Mi , Paolo Lucente , Tim Evens
2018-12-19
03 Tim Evens Uploaded new revision
2018-11-09
02 Job Snijders Changed consensus to Yes from Unknown
2018-11-09
02 Job Snijders Intended Status changed to Proposed Standard from None
2018-11-09
02 Job Snijders IETF WG state changed to In WG Last Call from WG Document
2018-09-17
02 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-02.txt
2018-09-17
02 (System) New version approved
2018-09-17
02 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Shunwan Zhuang , Kevin Mi , Paolo Lucente , Tim Evens
2018-09-17
02 Tim Evens Uploaded new revision
2018-09-03
01 (System) Document has expired
2018-03-13
01 Job Snijders Added to session: IETF-101: grow  Mon-1740
2018-03-02
01 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-01.txt
2018-03-02
01 (System) New version approved
2018-03-02
01 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Shunwan Zhuang , Kevin Mi , Paolo Lucente , Tim Evens
2018-03-02
01 Tim Evens Uploaded new revision
2017-12-23
00 (System) Document has expired
2017-07-13
00 Peter Schoenmaker Added to session: IETF-99: grow  Mon-1740
2017-06-21
00 Chris Morrow This document now replaces draft-evens-grow-bmp-adj-rib-out instead of None
2017-06-21
00 Tim Evens New version available: draft-ietf-grow-bmp-adj-rib-out-00.txt
2017-06-21
00 (System) WG -00 approved
2017-06-16
00 Tim Evens Set submitter to "Tim Evens ", replaces to draft-evens-grow-bmp-adj-rib-out and sent approval email to group chairs: grow-chairs@ietf.org
2017-06-16
00 Tim Evens Uploaded new revision