Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt

Robert Raszuk <robert@raszuk.net> Fri, 18 October 2013 18:39 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: l3vpn@ietfa.amsl.com
Delivered-To: l3vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8A011E826F for <l3vpn@ietfa.amsl.com>; Fri, 18 Oct 2013 11:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.279
X-Spam-Level:
X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoFSRbC5FewX for <l3vpn@ietfa.amsl.com>; Fri, 18 Oct 2013 11:39:37 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D554411E81B8 for <l3vpn@ietf.org>; Fri, 18 Oct 2013 11:39:30 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so7003073iec.6 for <l3vpn@ietf.org>; Fri, 18 Oct 2013 11:39:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7MivTJsOtLmLlmWdvZ4h9krdT68MUYhKRBHviJTNseY=; b=YPGUFECmNrcvF7SR444gnrF/0UEuYCP1B5lNZbmeSY38y4l8K5pvW2ywnl2O8Tbkzu MuO3EqFQqb5vn5Hiod+PQwxVVimcW1stZqkXkwY0MY0dqreAfKJDNWJe4P8FT94QcWZU +bT3KtJD2uqOIdnQrkyPV20sjd1GvC1W68fUVOvCLuDxkB2NMAfFymnwjEKi8WJ1lrfH d744AV3iWbY2o59ENH/EaMuz4SGs6BB00BKQEIKr5ixuZnoOMh6FruXNtby3okg0Urwv 8o28QZRDrKh4zrk86vr6mzdLvaue9ccdtzR09nfXZDM/jW7OkY8Um1hNf9+sTPk8QuuC nbKg==
MIME-Version: 1.0
X-Received: by 10.43.138.8 with SMTP id iq8mr2747200icc.37.1382121570244; Fri, 18 Oct 2013 11:39:30 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Fri, 18 Oct 2013 11:39:30 -0700 (PDT)
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com>
References: <d5998f73e66449b5ac7422fab129a332@CO1PR05MB442.namprd05.prod.outlook.com> <CA+b+ERm4j3Ht7dsMjBR41R14wVzLhLgMNdqjjiejNewsgNDURg@mail.gmail.com> <09924afe39144caf8718bf18e634dc6b@CO1PR05MB442.namprd05.prod.outlook.com> <CA+b+ERki_avz3hmo746=NfDa95va0X=a220hiCof2fOnRdqREQ@mail.gmail.com> <CA+b+ER=Y0b4ryfQ+fH4BA70YFAP51V-NwpDNeQjeQ3C_waqv1A@mail.gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452D7BF0@dfweml509-mbx.china.huawei.com>
Date: Fri, 18 Oct 2013 20:39:30 +0200
X-Google-Sender-Auth: UEaUEneil1l2K1GOqWJXpK938yw
Message-ID: <CA+b+ERkASVOY-0p2j+=TnNZjU3+xU4Dx5uUyuvt+4+xtaFFmsA@mail.gmail.com>
Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt
From: Robert Raszuk <robert@raszuk.net>
To: Lucy yong <lucy.yong@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2013 18:39:39 -0000

Lucy,

> [Lucy] why do you think that this mechanism is simpler than the one
> proposed in the draft? To me, it just shifts the request capability outside
> BGP. It makes BGP simple, but not necessary mean the solution simpler.

The main point is not about using BGP or not. Here if anything
industry and in particular this WG has been converging to use RT
Constrain for controlling VPN route distribution. This draft however
now proposed ORF which runs over Route Refresh. That means that at
least one benefit of RTC is lost - incremental updates.

In fact I would say this is a grey area how to run RTC and ORF
together for the same set of VRFs.

My focus was not to debate about using BGP rather the focus is to use
right tool for the task.

Imagine I have deployed another L3VPN WG document namely:
draft-ietf-l3vpn-end-system-01

In such architecture I have decoupled for a number of good reasons
data plane and control plane to completely different physical boxes.
Note also that in such design I already have on the complete system a
stats collector where it is really trivial to trigger a message to
v-hub in order to inject more specifics.

Contrary if I am to use proposed solution I need to modify XMPP as
well as number of other system wide components to achieve the goal.

Best regards,
R.