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

From: Xiejingrong <[email-masked]>
Date: Fri, 11 Jan 2019 04:09:40 +0000

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-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 29, 2018 12:27 AM
To: [email-masked]
Cc: [email-masked]
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-masked]
https://www.ietf.org/mailman/listinfo/bess

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 11 Jan 2019 19:28:47 +0000

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

> From: Xiejingrong [mailto:[email-masked]]
> Sent: Thursday, January 10, 2019 11:10 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action:
> draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Hi,
> 
> 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.
> 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 ?
> 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=
> 
> 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=
> 
> 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.
> 
> 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=
> 
> 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=

---

From: Xiejingrong <[email-masked]>
Date: Wed, 23 Jan 2019 01:47:06 +0000

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:[email-masked]] 
Sent: Saturday, January 12, 2019 3:29 AM
To: Xiejingrong <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

Jingrong,

Jeffrey

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Jan 2019 16:32:15 +0000

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

> Sent: Tuesday, January 22, 2019 8:47 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; draft-ietf-bess-mvpn-expl-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Hi Jeffrey,
> 
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Jingrong,
>

---

From: Xiejingrong <[email-masked]>
Date: Thu, 24 Jan 2019 02:09:14 +0000

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://www.rfc-editor.org/errata/eid5605

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Thursday, January 24, 2019 12:32 AM
To: Xiejingrong <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

Hi Jingrong,

Jeffrey

> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; 
> draft-ietf-bess-mvpn-expl- [email-masked]
> Cc: [email-masked]
> The sender PE need to work on (*,*) tunnel for a while (switch-over 
> timer) and then switch to the (S,G) tunnel.
> 
> > (C-S, C-G)
> into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE 
> should work correctly in any case.
> 
> > *ONE* 'Match for Reception' S-PMSI A-D route, and setup the 
> > 'reception state' only for the 'Matched' S-PMSI A-D route.
> > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_inte
> > rn
> > et-

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 24 Jan 2019 02:40:30 +0000

The receiver PE cannot keep its state to receive on both tunnels forever. After some time, it has to leave the old tunnel.

Jeffrey

> Sent: Wednesday, January 23, 2019 9:09 PM
> I have the same understanding "the text in RFC6625 is really/mainly about
> which tunnel to send/receive on in a steady state."
> 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.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
> 2Deditor.org_errata_eid5605&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK
> -
> m=uchRmclZ5z8wB9eN53Kr24c9zLtM9RBRe8OnA3FK1fM&s=cbCycqc2jZy8SjT
> LHS4AEL_UhljIoaGGWAnycB0VvrY&e=
> 
> 
> 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
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Jan 2019 08:35:39 -0500

Hi Jeffrey,

Isn't this just a matter of how you would be implementing "tunneling" ?

For vast majority of decapsulations there is no state as such, but it is
just part of one of normal switching vectors in the router.

Best,
R.

On Wed, Jan 23, 2019, 21:40 Jeffrey (Zhaohui) Zhang <[email-masked]
wrote:

> The receiver PE cannot keep its state to receive on both tunnels forever.
> After some time, it has to leave the old tunnel.
>
> Jeffrey
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 24 Jan 2019 13:50:29 +0000

Robert,

You may want to leave the previous tunnel (if it is no longer needed for other traffic). E.g., sending an mldp label withdrawal or withdrawing a Leaf A-D route.

Jeffrey

From: Robert Raszuk [mailto:[email-masked]]
Sent: Thursday, January 24, 2019 8:36 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Xiejingrong <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

Hi Jeffrey,

For vast majority of decapsulations there is no state as such, but it is just part of one of normal switching vectors in the router.

Best,
R.

On Wed, Jan 23, 2019, 21:40 Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]> wrote:
The receiver PE cannot keep its state to receive on both tunnels forever. After some time, it has to leave the old tunnel.

Jeffrey

> From: Xiejingrong [mailto:[email-masked]<mailto:[email-masked]>]
> To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; draft-ietf-bess-mvpn-expl-
> [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]<mailto:[email-masked]>]
> To: Xiejingrong <[email-masked]<mailto:[email-masked]>>; draft-ietf-bess-mvpn-expl-
> [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> > From: Xiejingrong [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>;
> > draft-ietf-bess-mvpn-expl- [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Xiejingrong <[email-masked]<mailto:[email-masked]>>; draft-ietf-bess-mvpn-expl-
> > [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > > From: Xiejingrong [mailto:[email-masked]<mailto:[email-masked]>]
> > > To: [email-masked]<mailto:[email-masked]>
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > From: BESS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of internet-
> > > [email-masked]<mailto:[email-masked]>
> > > To: [email-masked]<mailto:[email-masked]>
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > submission until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=XEB2lmyuTS4A17K8QRo-Ybpdyt9FOiqZUKnX2Fn8tzM&s=e5YePxkaclxFPzRjZuLU2RlQ4q7QZYgM0VQWmoG7vbU&e=>.
> > >
> > > [email-masked]<mailto:[email-masked]>

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=XEB2lmyuTS4A17K8QRo-Ybpdyt9FOiqZUKnX2Fn8tzM&s=bXsDKDe02acwmIBmiFiiprMy4Y9xkq0ocOf7mb2yGJ8&e=>

---

From: Xiejingrong <[email-masked]>
Date: Fri, 25 Jan 2019 01:49:27 +0000

Hi Jeffrey,

Wildcard S-PMSI A-D routes is less specific and more “inclusive” than the normal S-PMSI.
Among which, Wildcard (*,*)S-PMSI A-D route is the most “inclusive”, almost equal to I-PMSI A-D route. See RFC6625 “S-PMSI only”.
Leaf will not leave the real I-PMSI tunnel, so it should not leave the Wildcard(*,*)/(*,G)/(S,*) S-PMSI tunnel either, because they are “partially inclusive” tunnel.

Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, January 24, 2019 9:50 PM
To: Robert Raszuk <[email-masked]>
Cc: Xiejingrong <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

Robert,

Jeffrey

From: Robert Raszuk [mailto:[email-masked]]
Sent: Thursday, January 24, 2019 8:36 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Xiejingrong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

Hi Jeffrey,

Best,
R.

Jeffrey