Benjamin, Not speaking for the authors, but as an interested vendor:
On Mon, Jul 08, 2019 at 03:40:44PM -0700, Benjamin Kaduk via Datatracker 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? 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. > 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? 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
