RE: WG Last Call for draft-ietf-l3vpn-mvpn-bidir

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 28 April 2014 21:23 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: l3vpn@ietfa.amsl.com
Delivered-To: l3vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7531A6F50 for <l3vpn@ietfa.amsl.com>; Mon, 28 Apr 2014 14:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 GEz8DO8Cdiod for <l3vpn@ietfa.amsl.com>; Mon, 28 Apr 2014 14:23:29 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2339F1A07A2 for <l3vpn@ietf.org>; Mon, 28 Apr 2014 14:23:28 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) with Microsoft SMTP Server (TLS) id 15.0.921.12; Mon, 28 Apr 2014 21:23:25 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.201]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.201]) with mapi id 15.00.0921.000; Mon, 28 Apr 2014 21:23:24 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Eric Rosen <erosen@cisco.com>, L3VPN <l3vpn@ietf.org>
Subject: RE: WG Last Call for draft-ietf-l3vpn-mvpn-bidir
Thread-Topic: WG Last Call for draft-ietf-l3vpn-mvpn-bidir
Thread-Index: AQHPYLkm/TRkLGMfDE6A4LyFsBpqBJsnav2Q
Date: Mon, 28 Apr 2014 21:23:24 +0000
Message-ID: <7ec54baf59f741ab9f4b996370957898@BY2PR05MB079.namprd05.prod.outlook.com>
References: <535A3E8C.3040508@orange.com>
In-Reply-To: <535A3E8C.3040508@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.11]
x-forefront-prvs: 01952C6E96
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(41574002)(199002)(189002)(377454003)(51704005)(13464003)(54356999)(74502001)(81542001)(2656002)(20776003)(66066001)(74316001)(19580395003)(74662001)(80022001)(81342001)(101416001)(76176999)(99286001)(31966008)(76576001)(87936001)(15975445006)(15202345003)(50986999)(80976001)(92566001)(4396001)(77982001)(19580405001)(86362001)(99396002)(76482001)(33646001)(46102001)(83322001)(79102001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB078; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:F8DDF465.A8FA5F49.31D9AC4C.82C523BD.203DA; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/l3vpn/PIFN9km6APZucCECCXYIpIPG6oI
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 28 Apr 2014 21:23:33 -0000

Eric,

We had some offline discussions/updates before. Now just some minor comments for the WGLC.

There are the following two paragraphs in their respective sections:

   When the Flat Partitioned Method is used to implement the
   "Partitioned Sets of PEs" method of supporting C-BIDIR, as discussed
   in section 11.2 of [MVPN] and section 3.6 of [RFC6517], a C-BIDIR
   flow MUST be carried only on an I-PMSI or on a (C-*,C-G-BIDIR),
   (C-*,C-*-BIDIR), or (C-*,C-*) S-PMSI.  A PE MUST NOT originate any
   (C-S,C-G-BIDIR) S-PMSI A-D routes. (Though it may of course originate
   (C-S,C-G) S-PMSI A-D routes for C-G's that are not C-BIDIR groups.)
   Packets of a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI.

   ...

   When the Hierarchical Partitioned Method is used to implement the
   "Partitioned Sets of PEs" method of supporting C-BIDIR, as discussed
   in section 11.2 of [MVPN] and section 3.6 of [RFC6517], a C-BIDIR
   flow MUST be carried only on an I-PMSI or on a (C-*,C-G-BIDIR),
   (C-*,C-*-BIDIR), or (C-*,C-*) S-PMSI.  A PE MUST NOT originate any
   (C-S,C-G-BIDIR) S-PMSI A-D routes. (Though it may of course originate
   (C-S,C-G) S-PMSI A-D routes for C-G's that are not C-BIDIR groups.)
   Packets of a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI.

Clearly, there is no difference between hierarchical partition and flat partition in this regard.
Therefore, maybe just keep the last two sentences, and move it to another appropriate common place (e.g., somewhere in section 1.2.4):

   A PE MUST NOT originate any (C-S,C-G-BIDIR) S-PMSI A-D routes.
   Packets of a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI.

The following does not seem to be correct in 3.2.2:

   As in [MVPN] and [MVPN-BGP], an S-PMSI A-D route does not need to be
   originated by a particular PE, say PE1, until PE1 has received a
   "join" indicating that some other PE is interested in receiving a
   C-flow whose C-S or C-RP(A) is reachable from PE1 via a VRF
   interface.

For example, if the S-PMSI is used to carry unidirectional traffic from PE2 (not PE1), or to carry bidirectional traffic on sender-only branches?

For the following in 3.2.2.2:

   Note that the PE Distinguisher Label to be used is the one assigned
   by the root of the P-tunnel to the address of PE2, not the one
   assigned to the address of PE1.  Note also that the root of the
   P-tunnel might be a PE other than PE1 or PE2.

It is for bidirectional flows. For unidirectional flows, the label assigned by the root for PE1 need to be used.

3.2.2.3. When an I-PMSI is a 'Match for Transmission'

   ...

   If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the
   rules as applied by PE1 are the same as those given in section
   3.2.1.2.

3.2.1.2 does not talk about labels. We should add some text here about labels.

Thanks!

Jeffrey

> -----Original Message-----
> From: Thomas Morin [mailto:thomas.morin@orange.com]
> Sent: Friday, April 25, 2014 6:53 AM
> To: L3VPN
> Subject: WG Last Call for draft-ietf-l3vpn-mvpn-bidir
> 
> Hello working group,
> 
> This email starts a Working Group Last Call on
> draft-draft-ietf-l3vpn-mvpn-bidir, which is considered mature and ready
> for a last call working group review.
> 
> Please read the document if you haven't read the most recent version
> yet, and send your comments to the list, no later than **May 10th**.
> 
> Thank you,
> 
> -Thomas & Martin
> 
> [ http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-bidir ]
>