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."
- WG Last Call for draft-ietf-l3vpn-mvpn-bidir Thomas Morin
- RE: WG Last Call for draft-ietf-l3vpn-mvpn-bidir Jeffrey (Zhaohui) Zhang
- Re: WG Last Call for draft-ietf-l3vpn-mvpn-bidir Eric Rosen
- RE: WG Last Call for draft-ietf-l3vpn-mvpn-bidir Jeffrey (Zhaohui) Zhang
- Re: WG Last Call for draft-ietf-l3vpn-mvpn-bidir Thomas Morin
- draft-ietf-l3vpn-mvpn-bidir back to the working g… Thomas Morin
- (2nd) WG Last call on draft-ietf-l3vpn-mvpn-bidir… Thomas Morin
- Re: (2nd) WG Last call on draft-ietf-l3vpn-mvpn-b… Thomas Morin