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-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Thursday, November 29, 2018 12:27 AM
To: i-d-annou...@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 
        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

BESS mailing list

Reply via email to