Below are comments.
** Section 4, Extension of BMP Initiation Message: I suppose there are two ways to encode bgp optional params and default behaviors. We could encode all in the single info TLV where the info length is the total length in bytes of all encoded sub-tlv's. Alternatively, we could repeat the info TLV's where only a subset of the sub-tlv's are encoded. BGP capabilities works this way today, which IMO is a bit of a pain because we have to support both. IMHO, I would prefer to pick one. For example, call out that only one TBD1 and TDB2 can be present in an init message. This would require the single info TLV to encode all sub-tlv's. For example, info tlv TBD1 (bgp caps) length would encode all bgp caps as an array of param sub-tlv's. TBD3 - TBD12 should probably refence (rfc/draft links) the attribute values indicated. For example, local pref is well known and encoded as a 32-bit "unsigned" int. This draft doesn't call out that it's unsigned or signed, but if we know it's referring to the local-pref attribute, then we know it's unsigned and the value range allowed. Other than the above, it looks good from initial review. Thanks, Tim On 7/2/18, 7:00 PM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email protected] on behalf of [email protected]> wrote: Hi all, We have uploaded two drafts on BMP extensions. "draft-gu-grow-bmp-vpn-label" proposes the idea of using BMP to collect VPN labels for applications such as traffic optimization. "draft-zhuang-grow-monitoring-bgp-parameters" proposes to use BMP to collect BGP parameters: capacity and default behavior. The capacity parameters (both enabled and not enabled) are reported to the BMP server for better network optimization. The default behavior parameters, such as vendor-specific protocol preferences, are reported for multi-vendor interoperation. Comments and suggestions are welcome! Thanks! Yunan
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
