Subject: Re: [GROW] I-D Action: draft-gu-grow-bmp-vpn-te-00.txt

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Mar 2019 15:00:15 +0100

Dear authors of this draft,

Please kindly clarify why vpn traffic engineering requires any extensions
to BMP ? The only justification I found in your draft is following:

"   All in all, it's more efficient to collect the MPLS VPN label
   independently than extracting it from VPNv4 routes."

I would challenge if it is indeed more efficient to upgrade 100s of PEs,
add completely new functionality to current bmp code and then split in some
implmentations very limited number of bmp sessions out of those PEs into
multiple controllers/monitoring tools as opposed to simply parse vpnv4
updates on x86 controller.

VPN labels along with routes and next hops can be learned by your traffic
engineering controller  over vpnv4 sessions since it already needs to speak
vpnv4 SAFI anyway to advertise the "engineered" routes back to the network
devices.

It can advertise it with higher local preference to enforce his routes to
be used as alternative reachability information which could be already
present for example via traditional route reflection.

Besides these days to get any information from a router BGP-LS SAFI is
targetted so I am highly puzzled what triggered idea of now start extending
BMP with similar objectives.

Regards,
RR.

On Mon, Mar 11, 2019 at 1:40 PM <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : VPN Traffic Engineering Using BMP
>         Authors         : Yunan Gu
>                           Jie Chen
>                           Penghui Mi
>                           Shunwan Zhuang
>                           Zhenbin Li
>         Filename        : draft-gu-grow-bmp-vpn-te-00.txt
>         Pages           : 10
>         Date            : 2019-03-11
>
> 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 traffic engineering (TE)
>    method in the VPN (Virtual Private Network) scenario using BMP.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gu-grow-bmp-vpn-te/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-gu-grow-bmp-vpn-te-00
> https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-te-00
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Wed, 13 Mar 2019 08:00:05 +0000

Hi Robert,

Thanks a lot for the comment!

First of all, let me clarify the very specific application scenario here. We are discussing a VPN egress traffic optimization case considering one single VPN domain only.

Agree that the MPLS VPN label is able to be extracted from the VPNv4 routes, which can be either collected by monitoring the MP-BGP session between two PEs using BMP or setting up a VPNv4 session between device and controller. However, the usage of such intra-domain VPNv4 routes are very limited. To the best of my knowledge, it’s only used for TE currently. While for TE purpose, only the prefix + VRF + label information from the VPNv4 routes are needed. Considering that VRF and label are not necessarily per route based (e.g., the per VRF/CE per label cases), VRF and label can be only reported once using BMP extension compared with the per route report of VPNv4 if no label assignment change happens. It saves both CPU and bandwidth resources. Even for the per route per label case, only prefix +VRF + label are reported using BMP instead of prefix + VRF + label + attributes using VPNv4. Again saves resources.

We think using BMP for VPN TE is another option considering the existing methods, such as BGP-LS EPE or BGP-LU EPE solutions. Operators may have multiple choices and choose the one that best fits their current deployment.

BR,

Yunan

From: GROW [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, March 11, 2019 10:00 PM
To: [email-masked]
Subject: Re: [GROW] I-D Action: draft-gu-grow-bmp-vpn-te-00.txt

Please kindly clarify why vpn traffic engineering requires any extensions to BMP ? The only justification I found in your draft is following:

I would challenge if it is indeed more efficient to upgrade 100s of PEs, add completely new functionality to current bmp code and then split in some implmentations very limited number of bmp sessions out of those PEs into multiple controllers/monitoring tools as opposed to simply parse vpnv4 updates on x86 controller.

VPN labels along with routes and next hops can be learned by your traffic engineering controller  over vpnv4 sessions since it already needs to speak vpnv4 SAFI anyway to advertise the "engineered" routes back to the network devices.

It can advertise it with higher local preference to enforce his routes to be used as alternative reachability information which could be already present for example via traditional route reflection.

Besides these days to get any information from a router BGP-LS SAFI is targetted so I am highly puzzled what triggered idea of now start extending BMP with similar objectives.

Regards,
RR.

On Mon, Mar 11, 2019 at 1:40 PM <[email-masked]<mailto:[email-masked]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

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 traffic engineering (TE)
   method in the VPN (Virtual Private Network) scenario using 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<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>