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

Eric Rosen <erosen@cisco.com> Mon, 05 May 2014 15:51 UTC

Return-Path: <erosen@cisco.com>
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 803981A038B for <l3vpn@ietfa.amsl.com>; Mon, 5 May 2014 08:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.253
X-Spam-Level:
X-Spam-Status: No, score=-8.253 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 WOmQHYEB4KqI for <l3vpn@ietfa.amsl.com>; Mon, 5 May 2014 08:51:23 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id D4F121A037F for <l3vpn@ietf.org>; Mon, 5 May 2014 08:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3330; q=dns/txt; s=iport; t=1399305079; x=1400514679; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=EdtneZHapAAThPx0mhzAvWjV6hBvNqwazEUhKdCfzc0=; b=EFBLxL4sU74LmHUTWjTd2e2Tt4+H7ZncU/5LPv3jszZ34Z8qypw7qB3R iHqLDkgl6p5QJB77O36OU+qbcfwZVLS3wuso5B3DuXIBA5cYzv05jIocD QbEv8I+0lctrWsCzjtBOvYentg3Bu61i8WmH6AoMo5iwBXHXLL+vzQDx3 A=;
X-IronPort-AV: E=Sophos;i="4.97,988,1389744000"; d="scan'208";a="38635253"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 05 May 2014 15:51:18 +0000
Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s45FpIEH011331; Mon, 5 May 2014 15:51:18 GMT
Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id DDB7F783; Mon, 5 May 2014 11:51:17 -0400 (EDT)
From: Eric Rosen <erosen@cisco.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Subject: Re: WG Last Call for draft-ietf-l3vpn-mvpn-bidir
In-reply-to: Your message of Mon, 28 Apr 2014 21:23:24 -0000. <7ec54baf59f741ab9f4b996370957898@BY2PR05MB079.namprd05.prod.outlook.com>
Date: Mon, 05 May 2014 11:51:17 -0400
Message-ID: <24627.1399305077@erosen-lnx>
Archived-At: http://mailarchive.ietf.org/arch/msg/l3vpn/ZQF3ajl4akQxZ5kCDazat_aftIU
Cc: L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: erosen@cisco.com
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, 05 May 2014 15:51:26 -0000

Jeffrey, thanks for your comments.

> 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.

How about if I remove these paragraphs from section 3.2.1 and 3.2.2
respectively, and add a single paragraph at the front of section 3.2 that
begins "When either the Flat or the Hierarchical Partitioned method is used
..."

> 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?

I will remove this paragraph.

> 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.

Two paragraphs before the paragraph you cite it says "the remainder of this
section applies only to C\-BIDIR flows".  So your point is correct, but so
is the draft ;-)

> 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.

I think it is sufficient to add:

   "Note that if a matching I-PMSI A-D route is found, the PTA of that route
   will have a non-zero MPLS label.  This label must be pushed on each
   packet of the C-flow before that packet is transmitted through the
   P-tunnel identified in the PTA."