[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
- [bess] Kathleen Moriarty's No Objection on draft-… Kathleen Moriarty