The receiver PE cannot keep its state to receive on both tunnels forever. After some time, it has to leave the old tunnel.
Jeffrey > -----Original Message----- > From: Xiejingrong [mailto:xiejingr...@huawei.com] > Sent: Wednesday, January 23, 2019 9:09 PM > To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; 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 > > Hi Jeffrey, > > Thanks for the explaination. > I have the same understanding "the text in RFC6625 is really/mainly about > which tunnel to send/receive on in a steady state." > What confusing me is the "which tunnel to receive" decision, obviously on > receiver site PE. > > In my opinion, the receiver site PE should not do the decision, but be > prepared > to *any possible tunnel* that will be used by the sender site PE for a > specific > (S,G) flow. > Even in a steady state the sender site PE are using the (S,G) PMSI-tunnel for > a > (S,G) flow, the preparation on the (*,*)PMSI-tunnel should be kept on the > receiver site PE. > > Below is the errata report I have raised, and I hope it can be clarified. > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > 2Deditor.org_errata_eid5605&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK > - > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE& > m=uchRmclZ5z8wB9eN53Kr24c9zLtM9RBRe8OnA3FK1fM&s=cbCycqc2jZy8SjT > LHS4AEL_UhljIoaGGWAnycB0VvrY&e= > > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] > Sent: Thursday, January 24, 2019 12:32 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 > > Hi Jingrong, > > You're right that to avoid disruption and duplication a switchover delay is > needed on the source PE and desired on the receiver PE, and that means the > forwarding state needs to accommodate that. > > However, the text is in RFC6625 is really/mainly about which tunnel to > send/receive on in a steady state. That's not explicitly spelled out, but > that's > the intention per my understanding. > > To be more accurate, the text is about which PMSI route to match. In theory a > PMSI can be instantiated with one particular tunnel at one time and then > switch to another tunnel. In that case the PMSI route is updated with a > different PTA - the match to sending/receiving does not change yet the > switchover delay referred to RFC6513 still applies. > > Jeffrey > > > -----Original Message----- > > From: Xiejingrong [mailto:xiejingr...@huawei.com] > > Sent: Tuesday, January 22, 2019 8:47 PM > > To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; > > 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 > > > > 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=A3B4H8kLvLDD > > H > > > 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_inte > > > rn > > > et- > > > 2Ddrafts_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > > > > > > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE& > > > > > m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=LDR59TMdGZL > > W > > > 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
