Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

<thomas.morin@orange.com> Mon, 28 September 2015 07:34 UTC

Return-Path: <thomas.morin@orange.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 255B01A6F32; Mon, 28 Sep 2015 00:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.604
X-Spam-Level:
X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
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 JRABGzg0OhDF; Mon, 28 Sep 2015 00:34:27 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D381B31B7; Mon, 28 Sep 2015 00:34:26 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2BB743B42D6; Mon, 28 Sep 2015 09:34:25 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D504D4C073; Mon, 28 Sep 2015 09:34:24 +0200 (CEST)
Received: from [10.193.71.12] (10.197.38.3) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 28 Sep 2015 09:34:24 +0200
From: thomas.morin@orange.com
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" <draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org>
References: <D2298FF9.D375F%aretana@cisco.com> <CY1PR0501MB17215852447D81D0406DAF42D4420@CY1PR0501MB1721.namprd05.prod.outlook.com>
Organization: Orange
Message-ID: <9139_1443425665_5608ED80_9139_1087_2_5608ED80.6010405@orange.com>
Date: Mon, 28 Sep 2015 09:34:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CY1PR0501MB17215852447D81D0406DAF42D4420@CY1PR0501MB1721.namprd05.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------050506050001010202000803"
X-Originating-IP: [10.197.38.3]
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.131516
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/FPNhvzfJTRRVJudIBowa5oQBqMg>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Mon, 28 Sep 2015 07:34:28 -0000

Jeffrey, all,

[resending this one too...]

(below)

2015-09-25, Jeffrey (Zhaohui) Zhang:
>
> *From:*Alvaro Retana (aretana) [mailto:aretana@cisco.com]
>
>  5. Section 4. (Security Considerations)  Are there really no security
>     considerations?
>
>       * Section 3.1. (Control State)   Says that: "To speed up
>         convergence…PEy MAY advertise a Leaf A-D route even if does
>         not choose PEx as its Upstream PE…With that, it will receive
>         traffic from all PEs, but some will arrive with the label
>         corresponding to its choice of Upstream PE while some will
>         arrive with a different label, and the traffic in the latter
>         case will be discarded.”  I’m assuming that all the traffic
>         (specially the discarded one) belongs to the same VPN, so
>         there’s no danger of leaking information, right?  It might be
>         worth including something in the Security Consideration so
>         that it’s easier for the readers (Security Directorate, for
>         example) to grasp the context.
>
> Zzh> There is indeed no new issues. The quoted text refers to the 
> possible arrival of duplication for the same flow that the receiving 
> PEs need to receive, and they will be discarded anyway. There is no 
> deliver of duplication to CEs, and certainly there is no leaking. I am 
> not sure if that needs to be called out.
>
>

I agree on the analysis.
Refering to both RFC6513 and RFC6514 (instead of RFC6514 alone) is the 
only improvement I can think of.

Best,

-Thomas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.