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:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, March 11, 2019 10:00 PM
To: grow@ietf.org
Subject: Re: [GROW] I-D Action: draft-gu-grow-bmp-vpn-te-00.txt

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 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> 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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
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
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Reply via email to