[bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

Xiejingrong <xiejingrong@huawei.com> Fri, 11 January 2019 04:10 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E320112950A; Thu, 10 Jan 2019 20:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wLHOol2b7I38; Thu, 10 Jan 2019 20:10:03 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1512712785F; Thu, 10 Jan 2019 20:10:03 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 75D653022945794E15B6; Fri, 11 Jan 2019 04:09:58 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com ( by lhreml705-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 11 Jan 2019 04:09:57 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([]) with mapi id 14.03.0415.000; Fri, 11 Jan 2019 12:09:41 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "draft-ietf-bess-mvpn-expl-track@ietf.org" <draft-ietf-bess-mvpn-expl-track@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
Thread-Index: AdSpYQLeyyfnS0fsQTGEQTbsPNBRUA==
Date: Fri, 11 Jan 2019 04:09:40 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB7E5219@nkgeml514-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/sX3unfXenYvwiCV-cpUxPTDRu0s>
Subject: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 11 Jan 2019 04:10:05 -0000


I have a question regarding RFC6625 and this draft, since this draft is based on the RFC6625.

In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data Reception":
It defined the rules for Finding the matched S-PMSI A-D route for a (C-S,C-G) state on a receiver site PE.
It seems to me that, the receiver site PE will respond only to the *ONE* 'Match for Reception' S-PMSI A-D route, and setup the 'reception state' only for the 'Matched' S-PMSI A-D route.
But it is not true for an inclusive-selective relation between S-PMSI A-D (*,*) and S-PMSI A-D(S,G).
Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site PE with a (C-S,C-G) state should keep its join state on both the S-PMSI A-D (*,*) and S-PMSI A-D(S,G), and setup the 'reception state' on both the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel.
It is determined by the sender site PE whether to steer the flow of (C-S, C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE should work correctly in any case.

My question: 
Is the section 3.2.1 or RFC6625 wrong and should the 'Match for Reception' include *one or many* S-PMSI A-D routes ?
Is it a problem that can affect this draft ?


-----Original Message-----
From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Thursday, November 29, 2018 12:27 AM
To: i-d-announce@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

        Title           : Explicit Tracking with Wild Card Routes in Multicast VPN
        Authors         : Andrew Dolganow
                          Jayant Kotalwar
                          Eric C. Rosen
                          Zhaohui Zhang
	Filename        : draft-ietf-bess-mvpn-expl-track-13.txt
	Pages           : 21
	Date            : 2018-11-28

   The Multicast VPN (MVPN) specifications provide procedures to allow a
   multicast ingress node to invoke "explicit tracking" for a multicast
   flow or set of flows, thus learning the egress nodes for that flow or
   set of flows.  However, the specifications are not completely clear
   about how the explicit tracking procedures work in certain scenarios.
   This document provides the necessary clarifications.  It also
   specifies a new, optimized explicit tracking procedure.  This new
   procedure allows an ingress node, by sending a single message, to
   request explicit tracking of each of a set of flows, where the set of
   flows is specified using a wildcard mechanism.  This document updates
   RFCs 6514, 6625, 7524, 7582, and 7900.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

BESS mailing list