Hi, 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 ? Thanks Jingrong. -----Original Message----- From: BESS [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, November 29, 2018 12:27 AM To: [email protected] Cc: [email protected] 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 Abstract: 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: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-13 https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-13 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: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
