IETF Logo Mail Archive

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

"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 30 September 2015 16:01 UTC

Return-Path: <aretana@cisco.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 723FB1B5ED9; Wed, 30 Sep 2015 09:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.516
X-Spam-Level:
X-Spam-Status: No, score=-13.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 SkkYHPwMoRQ3; Wed, 30 Sep 2015 09:01:15 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7691B5EDE; Wed, 30 Sep 2015 09:01:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11201; q=dns/txt; s=iport; t=1443628867; x=1444838467; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NNz0z7sZOFUTMh6VX8pGgU/n1UEc4hL1fSqXcLF1XRw=; b=gtZuHMXos8b08x6IbWrHWSB1VAufFtT1RkzDLfeebDbSmc/gk1j22oPY kcCxc1QjB6lsSkciUyHcQkTjTduQvqXnfPMKuRHWSMgBxymAlYQsTCfm2 C4YigOF3KqH0BEx3iyZwYRXCVYvSsuoKKc3i/EpU0z9jpNw029kRrP2Hq I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AbAgC/BgxW/5JdJa1egldNVG0GvWkBDYF/hXUCgTc4FAEBAQEBAQGBCoQlAQEEeRACAQg/BzIUEQIEAQ0FiC4Ny1IBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzAYR8hQkEB4QsBZJGgzIBhRWHfZtQHwEBQoQCcQGIdIEFAQEB
X-IronPort-AV: E=Sophos; i="5.17,613,1437436800"; d="scan'208,217"; a="36804755"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 30 Sep 2015 16:01:06 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t8UG16On018344 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Sep 2015 16:01:06 GMT
Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Sep 2015 11:01:05 -0500
Received: from xhc-aln-x07.cisco.com (173.36.12.81) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 30 Sep 2015 11:01:05 -0500
Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 11:01:05 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "thomas.morin@orange.com" <thomas.morin@orange.com>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" <draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org>
Thread-Topic: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02
Thread-Index: AQHQ9t5VHlD7dQG6Pkan2vK2cWbI755NhaEQgAAksYCABF2HkIAAZeeAgAIPsoCAAI2PAIAAOayA
Date: Wed, 30 Sep 2015 16:01:05 +0000
Message-ID: <D2317102.D4731%aretana@cisco.com>
References: <D2298FF9.D375F%aretana@cisco.com> <CY1PR0501MB17215852447D81D0406DAF42D4420@CY1PR0501MB1721.namprd05.prod.outlook.com> <D22B0FDE.D3B90%aretana@cisco.com> <BLUPR0501MB1715DE33950F8876C858D530D44F0@BLUPR0501MB1715.namprd05.prod.outlook.com> <31952_1443454758_56095F26_31952_5125_1_56095F25.606@orange.com> <D230C622.D4588%aretana@cisco.com> <27441_1443598479_560B908F_27441_8335_1_560B908E.6040403@orange.com>
In-Reply-To: <27441_1443598479_560B908F_27441_8335_1_560B908E.6040403@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.27]
Content-Type: multipart/alternative; boundary="_000_D2317102D4731aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/1TCbdbLRrgGXn7ss6LLPBNj69NM>
Cc: "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: Wed, 30 Sep 2015 16:01:19 -0000

On 9/30/15, 2:34 AM, "thomas.morin@orange.com<mailto:thomas.morin@orange.com>" <thomas.morin@orange.com<mailto:thomas.morin@orange.com>> wrote:

Thomas:

Hi!

. . .
Current:

   The label may be shared
   with other P-tunnels, subject to the anti-ambiguity rules for
   extranet [I-D.ietf-bess-mvpn-extranet<https://tools.ietf.org/html/draft-ietf-bess-mvpn-bidir-ingress-replication-02#ref-I-D.ietf-bess-mvpn-extranet>].  For example, the (C-*,C-*-
   BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE
   can optionally share a label.

Proposed:
    These specifications do not prevent sharing of labels between P-tunnels, such as a label being shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route originated by a given PE (note that other specs put constraints on how that can be done, e.g. [I-D.ietf-bess-mvpn-extranet<https://tools.ietf.org/html/draft-ietf-bess-mvpn-bidir-ingress-replication-02#ref-I-D.ietf-bess-mvpn-extranet>]).


In fact, if the rules in ietf-bess-mvpn-extranet are not needed then don’t even mention them — referring to them just causes confusion as to whether they were needed.

I think that if this is clearly provided as an example then it can help the reader have the right context information to better understand the spec.

That works for me.   Just a nit: s/These specifications/This specification

. . .
Let's use RFC6513 section 2.1.2 as the reference for ingress replication, and eventually let the reader find out by himself when/if the IR-replication related materiel in this RFC is updated...

Fine with me too.

Thanks!

Alvaro.

v2.23.0 | Report a Bug | By Email