Subject: [GROW] Benjamin Kaduk's Discuss on draft-ietf-grow-bmp-adj-rib-out-06: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 08 Jul 2019 15:40:44 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-grow-bmp-adj-rib-out-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/

----------------------------------------------------------------------
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?

----------------------------------------------------------------------
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?

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 11 Jul 2019 10:15:13 -0400

Benjamin,

Not speaking for the authors, but as an interested vendor:

While underspecified, a general motivation is the ability to provide
information about a specific rib-out view.  In particular, since differing
BMP sessions may identify distint slices of the rib-out table, there's a
desire to provide additional information to the receiver about that view.
This may include such things as name of the view, peer group name, free form
description of the group, etc.  Such things are as much a matter of
preference of configuring the feature for use as it may be of an
implementation consideration.

With regard to the privacy considerations, they are identical to that of the
BMP base protocol.  See prior comment from Alvaro.

> implementations for convenience of administrators?

Some implementations, peer-groups are simply an administrative feature.  In
others, they have tight coupling toward the implementation.  Those
considerations are not part of RFC 4271 BGP-4 but are well understood by
BGP-4 operators.

-- Jeff

---

From: Paolo Lucente <[email-masked]>
Date: Tue, 16 Jul 2019 16:19:43 +0000

Hi Benjamin,

Thanks for your comments. The following edits address most of them:

https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/2134855587c0b98f24533aa66d76e05f3fa6ed29#diff-42c33450ab1d1f6d1ec35e9a12c7bf24

My comments inline:

On 9 Jul 2019, at 00:40, Benjamin Kaduk via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

I’d +1 the reply from Jeff on this.

Section 1

Yes. Jeff Haas proposed the edit below to draft-ietf-grow-bmp-loc-rib-04 — would the same/a similar edit address your point?

https://github.com/paololucente/draft-ietf-grow-bmp-loc-rib/blob/master/draft-ietf-grow-bmp-local-rib.txt#L682-L684

My feeling is that mentioning new statistics tyeps is too much detail for the introduction as well. While they integral part of the draft, they are not part of the core concept.

Section 4

encapsulated PDU was sent”?

You are right. I catched this before in fact you see the “Peer Address” description actually makes sense; we forgot to edit accordingly the other two, Peer AS and Peer BGP ID. I did the edit now.

I would propose to leave it underspecified as well, leaving it implementation specific.

Section 5.1

                                                              Some

Ack, i removed the “should also be set” part. I have also normalised language among the two places. I feel it is good to stress the concept in the two places, despite the text repetition.

Section 5.2

transmission”.

Ack, fixed.

Section 6.2

My take would be that it’s implied that bytes are transmitted as network byte order / big endian. rfc7854 does not specify this either. Nevertheless if it is felt a key detail, i can certainly add a remark about it.

Section 6.3

notifications”.

Agree, removed.

Section 7.1

I’d +1 the reply from Jeff on this.

Section 8

Ack, edited. Please see my reply to Alvaro.

Section 9.3

There is a draft undergoing to split Initiation Message and Peer Up message TLV registries, see https://tools.ietf.org/html/draft-scudder-grow-bmp-peer-up-00 , which makes a lot of sense and is being adopted by the WG. I look for suggestions on what would be the nicest way to address this.

Paolo

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Jul 2019 12:18:28 -0500

Hi Paolo,

> https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/2134855587c0b98f24533aa66d76e05f3fa6ed29#diff-42c33450ab1d1f6d1ec35e9a12c7bf24

Thanks.  The quoting seems a bit odd, but hopefully we can figure it out...

> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/

While Jeff's reply does help me personally to understand the motivation,
I'm left wondering what role I expect the final RFC itself to play in this
matter.  I think I'd like to see a brief mention in the Introduction that
this TLV is added in order to convey administrator-defined information
about the rib-out; is that consistent with your stance on the matter?

I'm not 100% sure  I'm looking at the right link -- the highlighted lines
are about requiring the Table Name to be sent when multiple filters are
applicable.  My question was intended to be about the wording here, about
whether "post policy would convey" should mention the possibility of new,
injected, data (in addition to changed or removed data).

> My feeling is that mentioning new statistics tyeps is too much detail for the introduction as well. While they integral part of the draft, they are not part of the core concept.

Fair enough.

> You are right. I catched this before in fact you see the “Peer Address” description actually makes sense; we forgot to edit accordingly the other two, Peer AS and Peer BGP ID. I did the edit now.

Thanks; it's reassuring to know that the problem was not on my end.

> I would propose to leave it underspecified as well, leaving it implementation specific.

I can understand that decision, even if I'm not fully comfortable actively
endorsing it.

> Ack, i removed the “should also be set” part. I have also normalised language among the two places. I feel it is good to stress the concept in the two places, despite the text repetition.

Thanks!

> My take would be that it’s implied that bytes are transmitted as network byte order / big endian. rfc7854 does not specify this either. Nevertheless if it is felt a key detail, i can certainly add…

I think  that it's probably best to just have the implicit "do what you did
for rfc7854" and not try to get super-precise here.

> I’d +1 the reply from Jeff on this.

If this is well-understood by the target  audience, I'm happy to live with
my minor confusion.

> Ack, edited. Please see my reply to Alvaro.

IIRC that looked fine.

> There is a draft undergoing to split Initiation Message and Peer Up message TLV registries, see https://tools.ietf.org/html/draft-scudder-grow-bmp-peer-up-00 , which makes a lot of sense and is bei…

I  think the responsible AD can handle this with the IANA interactions
during the publication/AUTH48 process.  Thanks for letting me know about
the other work in progress!

-Ben

---

From: Paolo Lucente <[email-masked]>
Date: Thu, 18 Jul 2019 16:13:38 +0000

Hi Benjamin,

Inline:

> On 17 Jul 2019, at 19:18, Benjamin Kaduk <[email-masked]> wrote:
>> 

Hoping it is not felt i am abusing this reason, i’d echo my comment on the new stats types: my feeling is that mentioning this optional TLV in the introduction is too much detail and while this is integral part of the draft, it is not a core concept. Shall, then, you ask me then what is the core concept of the draft, very legitimate question at this point, i’d tell you: adding new vantage points from which monitor BGP data. And abstract and Introduction both describe this concept at different - as it would be expexcted - resolution of detail. My proposal - also because to reach the point of describing the TLV one would have to speak about filtering and multi Loc-Rib - is to leave mention / full elaboration of this TLV in the relevant sections (6.3.1, 7.1 and 9.3) hoping they convey the same reasoning that Jeff mentioned in his previous email.

>> [ .. ]

Apologies, having done multiple edits, the lines changed. I was referring to the following piece of text:

“In case of any change that results in the alteration of behaviour of
an existing BMP session, ie. changes to filtering and table names,
the session MUST be bounced with a Peer DOWN/Peer UP sequence.”

Although this would be more relevant to the case of a policy change - i realize now, after your last email, a tangent.

To your point, i feel we are good, let me explain. Slightly before in the introduction we have:

"The Adj-RIB-In post-policy conveys to a BMP receiver all RIB data
after policy filters and/or modifications have been applied.”

Which says _all_ RIB data (that is: new, changed or removed). Then, continuing, an example is given:

“An example of pre-policy versus post-policy is when an inbound policy
applies attribute modification or filters."

Related to this we have the concluding sentence:

“Post policy would convey the changed data or would not contain the filtered data.” 

Where “changed” does not refer to new/changed/removed RIB data but rather to modified by the policy.

Having done some homeworks i feel i can also say: this paragraph was pretty much copy/pasted by rfc7854 :-)

>> [ .. ]
> [ .. ]

I see, i am open to suggestions on this point.

>> [ .. ]
> [ .. ]

Ack, thank you for the suggestion.

Paolo