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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Jingrong,

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

Why would the sender PE send into (*, *) when there is a match for (S,G)?

Jeffrey

> -----Original Message-----
> From: Xiejingrong [mailto:[e-mail]]
> Sent: Thursday, January 10, 2019 11:10 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action:
> draft-ietf-bess-mvpn-expl-track-13.txt
> 
> 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:[e-mail]] On Behalf Of internet-
> [e-mail]
> Sent: Thursday, November 29, 2018 12:27 AM
> To: [e-mail]
> Cc: [e-mail]
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> 2Dtrack_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=sbKFeLnAFP-
> zpT69P-oClnR4lbitbdaZYjOsDepCjxo&e=
> 
> There are also htmlized versions available at:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack-
> 2D13&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=jlPz-
> JVPIMj9q4cOW40qKs29IevDOPENoKn-oBQ3hK0&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> 2Dtrack-2D13&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=A3B4H8kLvLDDH
> AAYvRzveY09uFOBMr805O_uWxQmLRM&e=
> 
> A diff from the previous version is available at:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> 2Dtrack-2D13&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=TG7cPqa1m7LKi
> Hevo2tvZm4uqipF4gU6MDp0Q_jfEpQ&e=
> 
> 
> 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:
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-
> 2Ddrafts_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=LDR59TMdGZLW
> rvkvp_MJXRgt1FSLYgwTCFbUnRffKgE&e=
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bess&d=DwIFAg&c=HAkYuh63rsuhr6Sc
> bfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=BeypOtOdbV5x
> DkM3hqVLXSveWQuyJ3MSOBTj1itnAqY&e=