Hi Jeffrey, The sender PE need to work on (*,*) tunnel for a while (switch-over timer) and then switch to the (S,G) tunnel.
To quote RFC6513 section 7.1.1 The decision to bind a particular C-flow (designated as (C-S,C-G)) to a particular P-tunnel, or to switch a particular C-flow to a particular P-tunnel, is always made by the PE that is to transmit the C-flow onto the P-tunnel. When a C-flow is switched from one P-tunnel to another, the purpose of running a switch-over timer is to minimize packet loss without introducing packet duplication. Jingrong -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Saturday, January 12, 2019 3:29 AM To: Xiejingrong <xiejingr...@huawei.com>; draft-ietf-bess-mvpn-expl-tr...@ietf.org Cc: bess@ietf.org Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt 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:xiejingr...@huawei.com] > Sent: Thursday, January 10, 2019 11:10 PM > To: draft-ietf-bess-mvpn-expl-tr...@ietf.org > Cc: bess@ietf.org > 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: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 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_intern > et- > 2Ddrafts_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE& > m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=LDR59TMdGZLW > rvkvp_MJXRgt1FSLYgwTCFbUnRffKgE&e= > > _______________________________________________ > BESS mailing list > BESS@ietf.org > 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= _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
