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:tievens@cisco.com] 
Sent: Wednesday, July 18, 2018 12:24 AM
To: Zhuangshunwan <zhuangshunwan@huawei.com>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyunan@huawei.com>; jasonjchen@tencent.com; Mipenghui (Kevin Mi) <mipenghui@huawei.com>; Lizhenbin <lizhenbin@huawei.com>; 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 (https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15).

[Shunwan] It depends the customer's requirement, as I mentioned earlier,  the issue that we want to address is based on the BMP monitoring MPLS VPN scenario.	
Thanks again!
Shunwan et al

Thanks,
Tim

On 7/2/18, 7:00 PM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <grow-bounces@ietf.org on behalf of guyunan@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

    -----Original Message-----
    From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
    Sent: 2018年7月2日 16:05
    To: Lizhenbin <lizhenbin@huawei.com>; Mipenghui (Kevin Mi) <mipenghui@huawei.com>; Jie Chen <jasonjchen@tencent.com>; Zhuangshunwan <zhuangshunwan@huawei.com>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyunan@huawei.com>; iqjie@mail.ustc.edu.cn <jasonjchen@tencent.com>
    Subject: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt

    A new version of I-D, draft-gu-grow-bmp-vpn-label-00.txt
    has been successfully submitted by Yunan Gu and posted to the IETF repository.

    Name:		draft-gu-grow-bmp-vpn-label
    Revision:	00
    Title:		VPN Label Monitoring Using BMP
    Document date:	2018-07-02
    Group:		Individual Submission
    Pages:		8
    URL:            https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-vpn-label-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-gu-grow-bmp-vpn-label/
    Htmlized:       https://tools.ietf.org/html/draft-gu-grow-bmp-vpn-label-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-label

    Abstract:
       The BGP Monitoring Protocol (BMP) is designed to monitor BGP running
       status, such as BGP peer relationship establishment and termination
       and route updates.  This document provides a method of collecting the
       VPN label using BMP, as well as an implementation example.

    -------------------------------------------------------------------------------------------------------------------------------------------------
    -------------------------------------------------------------------------------------------------------------------------------------------------

    Name:		draft-zhuang-grow-monitoring-bgp-parameters
    Revision:	00
    Title:		Monitoring BGP Parameters Using BMP
    Document date:	2018-07-02
    Group:		Individual Submission
    Pages:		7
    URL:            https://www.ietf.org/internet-drafts/draft-zhuang-grow-monitoring-bgp-parameters-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-zhuang-grow-monitoring-bgp-parameters/
    Htmlized:       https://tools.ietf.org/html/draft-zhuang-grow-monitoring-bgp-parameters-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-zhuang-grow-monitoring-bgp-parameters

    Abstract:
       The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor
       BGP [RFC4271] running status, such as BGP peer relationship
       establishment and termination and route updates.  Without BMP, manual
       query is required if you want to know about BGP running status.

       This document provides the use cases that the BMP station can get the
       optional and default configure parameters of the monitored network
       device via BMP.

    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

    _______________________________________________
    GROW mailing list
    GROW@ietf.org
    https://www.ietf.org/mailman/listinfo/grow