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

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:[e-mail]]
> Sent: Wednesday, January 23, 2019 9:09 PM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; draft-ietf-bess-mvpn-expl-
> [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Thursday, January 24, 2019 12:32 AM
> To: Xiejingrong <[e-mail]>; draft-ietf-bess-mvpn-expl-
> [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> > Sent: Tuesday, January 22, 2019 8:47 PM
> > To: Jeffrey (Zhaohui) Zhang <[e-mail]>;
> > draft-ietf-bess-mvpn-expl- [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > Sent: Saturday, January 12, 2019 3:29 AM
> > To: Xiejingrong <[e-mail]>; draft-ietf-bess-mvpn-expl-
> > [e-mail]
> > Cc: [e-mail]
> > 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:[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=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
> > > [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=