Subject: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

From: Antoni Przygienda <[email-masked]>
Date: Wed, 3 Oct 2018 21:39:01 +0000

Based on consensus/request during IETF 102 this thread starts adoption request for https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

Please voice support/dissent/comments …

--- tony

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 3 Oct 2018 14:45:32 -0700

Yes/support

Cheers,
Jeff
On Oct 3, 2018, 2:39 PM -0700, Antoni Przygienda <[email-masked]>, wrote:
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 4 Oct 2018 00:27:40 +0000

Support as author J
Also want to disclose this IPR: https://datatracker.ietf.org/ipr/3234/

Thanks.
Jeffrey

From: BIER <[email-masked]> On Behalf Of Antoni Przygienda
Sent: Wednesday, October 3, 2018 5:39 PM
To: [email-masked]
Subject: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

Based on consensus/request during IETF 102 this thread starts adoption request for https://datatracker.ietf.org/doc/draft-zzhang-bier-php/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dzzhang-2Dbier-2Dphp_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=zyR-BjQcDQdDz9FUnhOQ-tCqTdJ9t7HEzO65JOB9icA&s=Mly-NYzhwUo4TOs_xXa_JXOrkqVj0JAjNxrBIXmgWd0&e=>

--- tony

---

From: "Purkayastha, Debashish" <[email-masked]>
Date: Thu, 4 Oct 2018 16:43:36 +0000

Support.

Debashish.

From: BIER [mailto:[email-masked]] On Behalf Of Antoni Przygienda
Sent: Wednesday, October 3, 2018 5:39 PM
To: [email-masked]
Subject: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

--- tony

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 4 Oct 2018 16:24:37 -0700

Hi,
yes/support the adoption of the draft.

Regards,
Greg

On Wed, Oct 3, 2018, 14:39 Antoni Przygienda <[email-masked]> wrote:

> Based on consensus/request during IETF 102 this thread starts adoption
> request for https://datatracker.ietf.org/doc/draft-zzhang-bier-php/
>
>
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 5 Oct 2018 01:50:40 +0000

Support thanks

Regards

Hooman

--- tony

---

From: Senthil Dhanaraj <[email-masked]>
Date: Fri, 5 Oct 2018 06:18:56 +0000

Support adoption !

Thanks,
Senthil

From: BIER [mailto:[email-masked]] On Behalf Of Antoni Przygienda
Sent: 04 October 2018 03:09
To: [email-masked]
Subject: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

--- tony

---

From: <[email-masked]>
Date: Mon, 8 Oct 2018 08:41:51 +0800 (CST)

Support adoption.

Thanks,

Sandy

原始邮件

发件人：AntoniPrzygienda <[email-masked]>
收件人：[email-masked] <[email-masked]>
日 期 ：2018年10月04日 05:39
主 题 ：[Bier] BIER WG adoption ofhttps://datatracker.ietf.org/doc/draft-zzhang-bier-php/

 

 

--- tony

---

From: <[email-masked]>
Date: Mon, 8 Oct 2018 10:05:57 +0800 (CST)

support

Regards,

Ran

原始邮件

发件人：GregMirsky <[email-masked]>
收件人：Antoni Przygienda <[email-masked]>
抄送人：BIER WG <[email-masked]>
日 期 ：2018年10月05日 07:24
主 题 ：Re: [Bier] BIER WG adoption ofhttps://datatracker.ietf.org/doc/draft-zzhang-bier-php/

Hi,

Regards, 

Greg 

 

 

--- tony

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 10 Oct 2018 15:08:52 +0200

Dear WG,

This is an interesting area, but for me there is clarification needed to support this draft as a WG document.

* When doing PHP, the BIER header is removed. That also removes the Context (for the upstream Label) of the packet, that is required to map it to the correct VPN or application. To me it sounds like this proposal does not work for MVPN and EVPN, but only global table Multicast. I assume that when a upstream assigned label is at the bottom of the BIER header, the BIER header is removed, and the Upstream label is left in place. How does the egress router know this label is upstream or downstream? By adding a global unique downstream Label into the Upstream label space you can probably solve that, but it needs to be documented this is a restriction.

* When there is no Upstream label below the BIER header, the Multicast packet is sent natively to the egress PE. How will the egress PE do the RPF check in order to accept the packet?

* This draft does require an upgraded software version of the Egress router in order to signal PHP, right? 

Thx,

Ice.

> On 3 Oct 2018, at 23:39, Antoni Przygienda <[email-masked]> wrote:
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 10 Oct 2018 14:15:35 +0000

Hi Ice,

Thanks for your comments and questions. Please see below.

> -----Original Message-----
> From: BIER <[email-masked]> On Behalf Of IJsbrand Wijnands
> Sent: Wednesday, October 10, 2018 9:09 AM
> To: Antoni Przygienda <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-
> zzhang-bier-php/
> 
> Dear WG,
> 
> * When doing PHP, the BIER header is removed. That also removes the Context
> (for the upstream Label) of the packet, that is required to map it to the correct
> VPN or application. To me it sounds like this proposal does not work for MVPN
> and EVPN, but only global table Multicast. I assume that when a upstream
> assigned label is at the bottom of the BIER header, the BIER header is removed,
> and the Upstream label is left in place. How does the egress router know this
> label is upstream or downstream? By adding a global unique downstream
> Label into the Upstream label space you can probably solve that, but it needs
> to be documented this is a restriction.

The draft does have the following:

   The procedures in this section can be applied only if, by means
   outside the scope of this document, it is known that one of the
   following conditions is met.

   o  The payload after BIER header is IPv4 or IPv6 (i.e., the Proto
      field in the BIER header is 4 or 6).
      Notice that in this case the Destination Address in the IPv4/IPv6
      header must be in the address space for the BIER layer.

   o  The payload after BIER header is MPLS packet with downstream-
      assigned label at top of stack (i.e., the Proto field in the BIER
      header is 2), For example, labels from a Domain-wide Common Block
      (DCB) are used as specified in [I-D.zzhang-bess-mvpn-evpn-
      aggregation-label].
> 
> * When there is no Upstream label below the BIER header, the Multicast
> packet is sent natively to the egress PE. How will the egress PE do the RPF
> check in order to accept the packet?

The egress RPF would either disable the RPF check or specify any "core interfaces" to be expected incoming interface. This is similar to using P2MP tunnels to send multicast traffic w/o signaling (a deployment scenario that has been supported by certain vendors already).

More importantly, I would expect MVPN/GTM/EVPN kind of deployment is the more appropriate scenario, where there will be a VPN/BD label used, which can associate the packets with a virtual RPF interface. If we're just transitioning an existing PIM deployment to using BIER, then there is no explicit set of edge routers (the premise of PHP is really that some edge routers, like VPN/EVPN PEs, cannot be upgraded to support BIER forwarding) - we can just run PIM if a router does not support BIER yet.

I can clarify this in the draft.

> order to signal PHP, right?

Yes - at least it does not require hardware upgrade :-)

Thanks!
Jeffrey

> request for https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dzzhang-2Dbier-
> 2Dphp_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=MHOYT0MTPnGU7-SyEX7XAKCB_PvAtekCQA8c_v34l88&s=eN3c_C-
> EyJQ3XqPzTCK6bVlK0US32ynkeG6QEsifoNQ&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbf
> h0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=MHOYT0MTPnGU7-
> SyEX7XAKCB_PvAtekCQA8c_v34l88&s=ky0R7wtyNi_WCqe036LclCNd38lc01Zl7
> lWnU0NEHLY&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbf
> h0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=MHOYT0MTPnGU7-
> SyEX7XAKCB_PvAtekCQA8c_v34l88&s=ky0R7wtyNi_WCqe036LclCNd38lc01Zl7
> lWnU0NEHLY&e=

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 10 Oct 2018 17:10:01 +0200

Hi Jeffrey, 

>      (DCB) are used as specified in [I-D.zzhang-bess-mvpn-evpn-

Ah, not sure why, I overlooked that part ;-) 

This solved my main objection, I support.

> I can clarify this in the draft.

Ok. 

> Yes - at least it does not require hardware upgrade :-)

Indeed,

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 10 Oct 2018 18:18:22 +0200

Jeffrey,

>> The egress RPF would either disable the RPF check or specify any "core interfaces" to be expected incoming interface. This is similar to using P2MP tunnels to send multicast traffic w/o signaling…

Thinking a bit more about this.. Disabling the RPF check I don’t like too much. Considering that modifications to the control-plane are allowed, it would be a good deployment practise to *always* advertise a downstream label, also for the global table scenario, maybe even make it mandatory for this solution... That way at least you can map the incoming interface to the BIER Virtual interface, which I think is good enough. Or, define BIER_IPV4_EXPLICIT_NULL and BIER_IPV6_EXPLICIT_NULL if we can get it. Something to consider..

Thx,

Ice.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 10 Oct 2018 19:52:30 +0000

Hi Ice,

> More importantly, I would expect MVPN/GTM/EVPN kind of deployment is the more appropriate scenario, where there will be a VPN/BD label used, which can associate the packets with a virtual RPF inter…

Notice the red text above – I am assuming you’re talking about BGP based overlay signaling.

Jeffrey

> From: IJsbrand Wijnands <[email-masked]>
> Sent: Wednesday, October 10, 2018 12:18 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Cc: Antoni Przygienda <[email-masked]>; [email-masked]
> >> The egress RPF would either disable the RPF check or specify any "core
> interfaces" to be expected incoming interface. This is similar to using P2MP
> tunnels to send multicast traffic w/o signaling (a deployment scenario that has
> been supported by certain vendors already).
>
> Thinking a bit more about this.. Disabling the RPF check I don’t like too much.
> Considering that modifications to the control-plane are allowed, it would be a
> good deployment practise to *always* advertise a downstream label, also for
> the global table scenario, maybe even make it mandatory for this solution...
> That way at least you can map the incoming interface to the BIER Virtual
> interface, which I think is good enough. Or, define BIER_IPV4_EXPLICIT_NULL
> and BIER_IPV6_EXPLICIT_NULL if we can get it. Something to consider..
>
> Thx,
>
> Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 10 Oct 2018 22:31:09 +0200

Hi Jeffrey,

I’m proposing to remove this section of the draft:

***
The payload after BIER header is IPv4 or IPv6 (i.e., the Proto
field in the BIER header is 4 or 6).
Notice that in this case the Destination Address in the IPv4/IPv6
header must be in the address space for the BIER layer.
***

If that is your thinking too, we are in sync.

Thx,

Ice.

> On 10 Oct 2018, at 21:52, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi Ice,
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 11 Oct 2018 18:09:09 +0000

Hi Ice,

Ah. Did not think we really needed to do that, but I am also fine with taking it out.

Thanks.
Jeffrey

> Sent: Wednesday, October 10, 2018 4:31 PM
> > > More importantly, I would expect MVPN/GTM/EVPN kind of deployment is
> the more appropriate scenario, where there will be a VPN/BD label used,
> which can associate the packets with a virtual RPF interface. If we're just
> transitioning an existing PIM deployment to using BIER, then there is no explicit
> set of edge routers (the premise of PHP is really that some edge routers, like
> VPN/EVPN PEs, cannot be upgraded to support BIER forwarding) - we can just
> run PIM if a router does not support BIER yet.
> >
> > > Subject: Re: [Bier] BIER WG adoption of
> 3A__datatracker.ietf.org_doc_draft-
> 2D&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> m=6NH_lDG9Fh-
> QvddiPTUCspTx6x_D6EEok2u0oAOis4w&s=MftHmWcEPIJPWFcQV8YlJ8ZJimUZ
> 67jpxRfRsFJcbXM&e=
> > > zzhang-bier-php/
> > >
> > > Jeffrey,
> > >

---

From: Mach Chen <[email-masked]>
Date: Fri, 12 Oct 2018 06:27:04 +0000

Yes/support.

Best regards,
Mach

From: BIER [mailto:[email-masked]] On Behalf Of Antoni Przygienda
Sent: Thursday, October 04, 2018 5:39 AM
To: [email-masked]
Subject: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

--- tony

---

From: Xiejingrong <[email-masked]>
Date: Fri, 12 Oct 2018 08:41:26 +0000

Hi Jeffrey,

The Proto field is 1 for downstream-assigned vpnlabel.

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Wednesday, October 10, 2018 10:16 PM
To: IJsbrand Wijnands <[email-masked]>; Antoni Przygienda <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-zzhang-bier-php/

Hi Ice,

> https://datatracker.ietf.org/doc/draft-
> zzhang-bier-php/
> 
> Dear WG,
> 
> * When doing PHP, the BIER header is removed. That also removes the 
> Context (for the upstream Label) of the packet, that is required to 
> map it to the correct VPN or application. To me it sounds like this 
> proposal does not work for MVPN and EVPN, but only global table 
> Multicast. I assume that when a upstream assigned label is at the 
> bottom of the BIER header, the BIER header is removed, and the 
> Upstream label is left in place. How does the egress router know this 
> Label into the Upstream label space you can probably solve that, but it needs to be documented this is a restriction.

> packet is sent natively to the egress PE. How will the egress PE do 
> the RPF check in order to accept the packet?

Thanks!
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 12 Oct 2018 11:19:28 +0000

You're right. I'll fix it.

Thanks!
Jeffrey

> From: Xiejingrong <[email-masked]>
> Sent: Friday, October 12, 2018 4:41 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; IJsbrand Wijnands
> <[email-masked]>; Antoni Przygienda <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Bier] BIER WG adoption of https://datatracker.ietf.org/doc/draft-
> zzhang-bier-php/
> 
> Hi Jeffrey,
> 
> m=i6zmTiVc58ZD0eHkVunIH7BgfZl360nCGfaURHbbwqM&s=zNwrxJ-
> q_HdmHozfYaZhxvXIuNoY7rWXeZkxDkBlRIM&e=
> 
> Hi Ice,
> 
> 2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> m=i6zmTiVc58ZD0eHkVunIH7BgfZl360nCGfaURHbbwqM&s=BC6UMqxSuTwj5
> HBr_XSngNxj06So_xV_gVN198jXxx4&e=
> > zzhang-bier-php/
> >
> > Dear WG,
> >
> More importantly, I would expect MVPN/GTM/EVPN kind of deployment is the
> more appropriate scenario, where there will be a VPN/BD label used, which
> can associate the packets with a virtual RPF interface. If we're just transitioning
> an existing PIM deployment to using BIER, then there is no explicit set of edge
> routers (the premise of PHP is really that some edge routers, like VPN/EVPN
> PEs, cannot be upgraded to support BIER forwarding) - we can just run PIM if a
> router does not support BIER yet.
> 
> m=i6zmTiVc58ZD0eHkVunIH7BgfZl360nCGfaURHbbwqM&s=eu9ww1wX6RiZJx
> B_37BjQSzc3Ydn66O0tBFjgMhxor4&e=

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 16 Oct 2018 15:30:40 +0200

Jeffrey,

Cool, I think taking it out is better.

Thx,

Ice.

> On 11 Oct 2018, at 20:09, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi Ice,
>