[bess] Kathleen Moriarty's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT)

"Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> Thu, 03 September 2015 00:09 UTC

Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB631B32BB; Wed, 2 Sep 2015 17:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc3IGZFlt6Aj; Wed, 2 Sep 2015 17:09:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77DF1A1BA3; Wed, 2 Sep 2015 17:09:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150903000902.17925.15201.idtracker@ietfa.amsl.com>
Date: Wed, 02 Sep 2015 17:09:02 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/SkK7cxT02pZsJWqTen5GUtnell0>
X-Mailman-Approved-At: Wed, 02 Sep 2015 22:05:43 -0700
Cc: draft-ietf-bess-mvpn-global-table-mcast@ietf.org, thomas.morin@orange.com, bess-chairs@ietf.org, bess@ietf.org
Subject: [bess] Kathleen Moriarty's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2015 00:09:05 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-bess-mvpn-global-table-mcast-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-global-table-mcast/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing the SecDir review questions.  I found the
explanation helpful and think some text in the draft would be good for
this particular question from the review since this is specific to this
draft:

[Cathy] What is not clear here is what is additional risk of information
leaking out into the wild the use of the GTM procedures proposed in this
document would incur. Does the use in a wider context mean that the
information is more widely distributed and thus has more chance of
leaking?

[Eric/Editor response] When L3VPN/MVPN is provisioned, each VRF is
configured with import RTs and export RTs. These RTs constrain the
distribution and the import of L3VPN/MVPN routes, making it difficult to
cause a route to be distributed to and imported by a VRF (or a global
table) that is not authorized to import that route. Additionally, VPN
routes do not go into the "global table" with the "ordinary Internet
routes" (i.e., non-VPN routes), and non-VPN routes do not impact the flow
of multicast data within a VPN.

In GTM, some of these protections against improper distribution/import of
the routes is lost. Import of the routes is not restricted to VRFs, and
the RT infrastructure that controls the distribution of routes among the
VRFs is not present when routes are exported from and imported into
global tables. But I don't think this needs to be explained in detail to
the intended audience of the draft, who will already be familiar with VPN
and MVPN technology.

SecDir Review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05940.html