Hi Benjamin, Inline:
> On 17 Jul 2019, at 19:18, Benjamin Kaduk <[email protected]> wrote: >> >> ---------------------------------------------------------------------- >> 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? >> >> I’d +1 the reply from Jeff on this. > > 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? 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. >> ---------------------------------------------------------------------- >> 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? >> >> Yes. Jeff Haas proposed the edit below to draft-ietf-grow-bmp-loc-rib-04 — >> would the same/a similar edit address your point? >> >> [ .. ] >> > > 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). 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 :-) >> [ .. ] > > [ .. ] > >> 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.) >> >> 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. I see, i am open to suggestions on this point. >> [ .. ] > > [ .. ] > >> 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? >> >> 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. > > 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! Ack, thank you for the suggestion. Paolo _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
