Re: [GROW] FW: New Version Notification for draft-zhuang-grow-monitoring-bgp-parameters-00.txt
Hi Tim, Thanks for your detailed review and good advice to this draft! Reply inline marked [Shunwan] Thanks, Shunwan et al From: Tim Evens (tievens) [mailto:tiev...@cisco.com] Sent: Wednesday, July 18, 2018 12:27 AM To: Zhuangshunwan ; Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; jasonjc...@tencent.com; Mipenghui (Kevin Mi) ; Lizhenbin ; grow@ietf.org Subject: Re: [GROW] FW: New Version Notification for draft-zhuang-grow-monitoring-bgp-parameters-00.txt 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. [Shunwan] Good advice, we will list all the options in the next version and do a comparative analysis to choose a better option. 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. [Shunwan] Will add in the next version. 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)" mailto:grow-boun...@ietf.org%20on%20behalf%20of%20guyu...@huawei.com>> 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] FW: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt
Hi Tim, Thanks for your detailed review and good advice to this draft! Reply inline marked [Shunwan] Thanks, Shunwan et al -Original Message- From: Tim Evens (tievens) [mailto:tiev...@cisco.com] Sent: Wednesday, July 18, 2018 12:24 AM To: Zhuangshunwan ; Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; jasonjc...@tencent.com; Mipenghui (Kevin Mi) ; Lizhenbin ; grow@ietf.org Subject: Re: [GROW] FW: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt Some comments below. ** Section 1, Introduction: "On the other hand, the labeled VPN routes are exchanged beween PE and PE, which could have been monitored by BMP but are currently not implemented due to the massive data exchange between the monitored devices and the BMP monitoring station." We support monitoring L3VPN and EVPN today in OpenBMP. For L3VPN, we normally see similar loads (data exchanges) as monitoring full IPv4 tables. Can you elaborate on how the L3VPN exchange is more than monitoring eBGP IPv4 transit peering (full IPv4 RIB)? I normally measure the load by initial RIB dump and then the incremental rate per NLRI.Currently, I see a typical IPv4 peer (pre-policy) with an incremental load of 12 NLRI's per second on average. [Shunwan] This sentence is not rigorous enough. “in certain implementation scenario” should be added at the end of this sentence. ** Section 2, Extension of BMP Peer Up Message: "If the Information Type is VPN Label, allocated per interface per label, the Information field should include the VPN label (20 bits label and 4 bits zero padding) and the corresponding interface address, with the total length specified in the Information Length field. One label and one interface address is allowed for each Information TLV." Which interface address? [Shunwan] The interface belongs to a VPN instance in a PE device and connects to a CE device "If the Information Type is VPN Label, allocated per route per label, the Information includes the VPN label (20 bits label and 4 bits zero padding) and the corresponding route prefix, with the total length specified in the Information Length field. The prefix should be in VPNv4 address format. One label and one prefix is allowed for each Information TLV." Isn't this forming a RIB now? Makes sense if it's peer or interface wide label because that is at peer scope. Encoding prefixes becomes a RIB at this point. Considering it's encoded in VPNv4 format, why not just encode this as a normal update for that AFI/SAFI? My initial thoughts are to reuse the VPNv4 afi/safi (or labeled unicast) BGP UPDATE message or create a new BMP type to encode VPN label to prefix mappings. [Shunwan] Good point! "per route per label" mode is not our goal, for completeness, just list it here. The real requirement is seeking a solution for peer or interface wide label mode. If the Information Type is VPN Label, allocated per next hop per label, the Information should include the VPN label (20 bits label and 4 bits zero padding) and the corresponding next hop address, with the total length specified in the Information Length field. One label and one next hop address is allowed for each Information TLV. This is also a RIB, but a rib of next-hops with associated labels, right? IMHO, encoding this as labeled unicast or as a new BMP type might make more sense. [Shunwan] Yes. Your suggestion is one of the future options to be considered. ** Section 3, Operation: I believe this is also the same use-case used for egress peer engineering/segment-routing. We do have a method to collect this today using https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15 and https://tools.ietf.org/html/draft-gredler-idr-bgplu-epe-11 . Do you have some other examples for the other types proposed? [Shunwan] I understand the method you mentioned here, but what we want to address is based on the BMP monitoring MPLS VPN scenario. In general, as I understand this draft, it is a method to convey single label to X mappings (e.g label RIB). Where X is either peer, vrf, interface, route/prefix, next-hop, etc. I'm leaning more towards a new BMP type instead of trying to convey this in peer up informational TLV's. The original RFC7854 draft doesn't completely define how to handle PEER UP's in terms of when to expect a new RIB dump or not. Currently, a new peer up can indicate that we should set all previous NLRI's as withdrawn and to expect a new RIB dump. Overloading the PEER UP to convey label mappings could complicate this. [Shunwan] Your understanding of this draft is correct! A new BMP type should be considered as one of the future options. We will add this option to this draft when we update.. The peer level labels might have overlap with egress peer engineering
[GROW] Presentation Materials for Meeting: Wed (tomorrow) July 18 2018
Howdy! If you thought: "Great idea, I'll present something wonderful in the GROW meeting this week!" and your name is not: "Dr Yunan Gu"... you owe presentation materials to the chairs now. If there is not a presentation in hand prior to 10am tomorrow morning I'll make one with ascii art... and I'm not really an artist... and ten point font on the screen will not go over well for the participants... send pdf, or I'll ascii art your pptwhatever into ten point font, thnx. -chris ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] FW: New Version Notification for draft-zhuang-grow-monitoring-bgp-parameters-00.txt
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)" 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] FW: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt
Some comments below. ** Section 1, Introduction: "On the other hand, the labeled VPN routes are exchanged beween PE and PE, which could have been monitored by BMP but are currently not implemented due to the massive data exchange between the monitored devices and the BMP monitoring station." We support monitoring L3VPN and EVPN today in OpenBMP. For L3VPN, we normally see similar loads (data exchanges) as monitoring full IPv4 tables. Can you elaborate on how the L3VPN exchange is more than monitoring eBGP IPv4 transit peering (full IPv4 RIB)? I normally measure the load by initial RIB dump and then the incremental rate per NLRI.Currently, I see a typical IPv4 peer (pre-policy) with an incremental load of 12 NLRI's per second on average. ** Section 2, Extension of BMP Peer Up Message: "If the Information Type is VPN Label, allocated per interface per label, the Information field should include the VPN label (20 bits label and 4 bits zero padding) and the corresponding interface address, with the total length specified in the Information Length field. One label and one interface address is allowed for each Information TLV." Which interface address? "If the Information Type is VPN Label, allocated per route per label, the Information includes the VPN label (20 bits label and 4 bits zero padding) and the corresponding route prefix, with the total length specified in the Information Length field. The prefix should be in VPNv4 address format. One label and one prefix is allowed for each Information TLV." Isn't this forming a RIB now? Makes sense if it's peer or interface wide label because that is at peer scope. Encoding prefixes becomes a RIB at this point. Considering it's encoded in VPNv4 format, why not just encode this as a normal update for that AFI/SAFI? My initial thoughts are to reuse the VPNv4 afi/safi (or labeled unicast) BGP UPDATE message or create a new BMP type to encode VPN label to prefix mappings. If the Information Type is VPN Label, allocated per next hop per label, the Information should include the VPN label (20 bits label and 4 bits zero padding) and the corresponding next hop address, with the total length specified in the Information Length field. One label and one next hop address is allowed for each Information TLV. This is also a RIB, but a rib of next-hops with associated labels, right? IMHO, encoding this as labeled unicast or as a new BMP type might make more sense. ** Section 3, Operation: I believe this is also the same use-case used for egress peer engineering/segment-routing. We do have a method to collect this today using https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15 and https://tools.ietf.org/html/draft-gredler-idr-bgplu-epe-11 . Do you have some other examples for the other types proposed? In general, as I understand this draft, it is a method to convey single label to X mappings (e.g label RIB). Where X is either peer, vrf, interface, route/prefix, next-hop, etc. I'm leaning more towards a new BMP type instead of trying to convey this in peer up informational TLV's. The original RFC7854 draft doesn't completely define how to handle PEER UP's in terms of when to expect a new RIB dump or not. Currently, a new peer up can indicate that we should set all previous NLRI's as withdrawn and to expect a new RIB dump. Overloading the PEER UP to convey label mappings could complicate this. The peer level labels might have overlap with egress peer engineering (https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15). Thanks, Tim On 7/2/18, 7:00 PM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" 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 -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: 2018年7月2日 16:05 To: Lizhenbin ; Mipenghui (Kevin Mi) ; Jie Chen ; Zhuangshunwan ; Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; iq...@mail.ustc.edu.cn Subject: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt A new version of I-D,
