Subject: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 25 Nov 2020 03:27:17 +0000

(to make clean, raise a new topic)

I am confused too by the claiming a solution can do everything and it is an "existing" solution, while requesting allocation of IPv6 Next Header / IPv4 Protocol value which is non-trivial.

We need to know, what does *the* BIERin6 draft propose, and how does *the* BIERin6 draft satisfy the bier-ipv6-requirements.
Take req-1 as an example, suppose there are PPP-over-SONET(POS, RFC2615) links in an IPv6 network, can the existing RFC8296 solve ? What does *the* BIERin6 draft propose to solve ?

Please note in my question the word *the* does not include anything that RFC8296 can solve. Any existing RFC8296 solution is not belonging to *the* BIERin6 proposal. Please tell us *the* BIERin6 proposal.
 
Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]] 
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

About the two lingering points it does shed light on something that has been disturbing me with the BIERin6 solution.

I thought about this some more and I think what creates a lot of confusion in my mind with BIERin6 solution is the L2/tunnel component.

As the main reason is that the L2/tunnel exists today with RFC 8296 “Non MPLS BIER Ethernet” with the special allocated next header code point to account for BIER next header 0xAB37.

I honestly think the L2 should be removed from the BIERin6 draft so that the optional IPV6 encapsulation is no longer “optional” in the draft as that now is the draft.

This also provides the “IPv6 encapsulation” commonality with BIERv6 at least showing clearly that their is a strive for commonality and parity between the two solutions.

Also the “muddying” of the water is eliminated by removing L2 making the solution crystal clear to operators.

Kind Regards

Gyan

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 24 Nov 2020 21:16:01 -0800

Please try to keep comments on track and in-line with the thread.
Stand-alone questions like this are just digging up ground we've already
sowed.

Thanks,
Shep

On Tue, Nov 24, 2020 at 7:27 PM Xiejingrong (Jingrong) <
[email-masked]> wrote:

> I am confused too by the claiming a solution can do everything and it is
> an "existing" solution, while requesting allocation of IPv6 Next Header /
> IPv4 Protocol value which is non-trivial.
>
> We need to know, what does *the* BIERin6 draft propose, and how does *the*
> BIERin6 draft satisfy the bier-ipv6-requirements.
> Take req-1 as an example, suppose there are PPP-over-SONET(POS, RFC2615)
> links in an IPv6 network, can the existing RFC8296 solve ? What does *the*
> BIERin6 draft propose to solve ?
>
> Please note in my question the word *the* does not include anything that
> RFC8296 can solve. Any existing RFC8296 solution is not belonging to *the*
> BIERin6 proposal. Please tell us *the* BIERin6 proposal.
>
> Thanks
> Jingrong
>
> Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>;
> [email-masked] <[email-masked]>; Tony Przygienda <
> [email-masked]>; draft-ietf-bier-ipv6-requirements <
> [email-masked]>; [email-masked]
> About the two lingering points it does shed light on something that has
> been disturbing me with the BIERin6 solution.
>
>
> I thought about this some more and I think what creates a lot of confusion
> in my mind with BIERin6 solution is the L2/tunnel component.
>
> As the main reason is that the L2/tunnel exists today with RFC 8296 “Non
> MPLS BIER Ethernet” with the special allocated next header code point to
> account for BIER next header 0xAB37.
>
> I honestly think the L2 should be removed from the BIERin6 draft so that
> the optional IPV6 encapsulation is no longer “optional” in the draft as
> that now is the draft.
>
> This also provides the “IPv6 encapsulation” commonality with BIERv6 at
> least showing clearly that their is a strive for commonality and parity
> between the two solutions.
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 25 Nov 2020 06:01:04 +0000

Why do you want to stop valid comments and valid discussions?
I think both Gyan and Jingrong just raised the key technique points.
Bier in 6 is just a wrong solution and direction.

Tianran

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Wednesday, November 25, 2020 1:16 PM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Please try to keep comments on track and in-line with the thread. Stand-alone questions like this are just digging up ground we've already sowed.

Thanks,
Shep

On Tue, Nov 24, 2020 at 7:27 PM Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> wrote:
(to make clean, raise a new topic)

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 25 Nov 2020 06:36:06 +0000

Because the chair does not seem to listen to the working group, at all.
Just a king, and didn’t show any transparency or expertise.

Thanks,
Jingrong

From: Tianran Zhou
Sent: Wednesday, November 25, 2020 2:01 PM
To: [email-masked]; Xiejingrong (Jingrong) <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: RE: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Tianran

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Wednesday, November 25, 2020 1:16 PM
To: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 25 Nov 2020 13:56:48 +0000

Please see zzh> below.

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]

Zzh> Comparing requesting a "next header" value for BIER, and specifying an IPv6 DOH to encode BIER and standardizing draft-xie-bier-ipv6-mvpn, which is more trivial?
Zzh> I want to point out that w/o draft-xie-bier-ipv6-mvpn, BIERv6 is not complete.

Zzh> How does IP work with POS? PPP header has a proto field - a new code point would be assigned for BIER. That is not IPv6 specific.

Zzh> *The* BIERin6 proposal is BIER over L2 and/or tunnels (IPv6 or not). In case of IPv6 tunnels, new code points are needed and that's why it needs to be on standards track, as I already explained.
Zzh> I had also explained already, why BIERin6 needs to explicitly spell out using *existing* solution (concept, not code point) for IPv6 network - we've wasted two years on this.

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Juniper Business Use Only

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 25 Nov 2020 14:14:17 +0000

Hi Tianran,

I had answered/countered every question/comment that Gyan/Jingrong raised, some repeatedly.

  *   Bier in 6 is just a wrong solution and direction.

Love to hear your arguments for the above.

Jeffrey

From: Tianran Zhou <[email-masked]>
Sent: Wednesday, November 25, 2020 1:01 AM
To: [email-masked]; Xiejingrong (Jingrong) <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: RE: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Tianran

Thanks,
Shep

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Si-OI7n2KWZpZrAUn6G14gDTm6ICWah6GxBVRm00DTGFWCb0rs1cnBoFCUdkIsCQ$>

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 25 Nov 2020 06:44:44 -0800

Comment in the thread please. Platitudes do not help move the discussion.

Shep

On Tue, Nov 24, 2020 at 10:01 PM Tianran Zhou <[email-masked]>
wrote:

> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Greg Shepherd
> *Sent:* Wednesday, November 25, 2020 1:16 PM
> *To:* Xiejingrong (Jingrong) <[email-masked]>
> *Cc:* Jeffrey (Zhaohui) Zhang <[email-masked]>; BIER WG <[email-masked]>;
> Gyan Mishra <[email-masked]>
> *Subject:* Re: [Bier] What does BIERin6 propose to satisfy the
> requirements? //RE: draft-ietf-bier-ipv6-requirements-09
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Nov 2020 10:29:13 -0500

Please see Gyan2>

On Wed, Nov 25, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Zzh> Comparing requesting a "next header" value for BIER, and specifying
> an IPv6 DOH to encode BIER and standardizing draft-xie-bier-ipv6-mvpn,
> which is more trivial?

    Gyan2> BIERv6 follows RFC 8200 specification in using DOH to encode
BIER for hop by hop en route processing.  MPLS BIER has an RFC 8556 for
MVPN even though it follows standard MVPN procedures RFC 6513 6514.  Non
MPLS BIER is not any different in that respect but also requires as in IPv6
environment uses SRv6 BGP Overlay Service.  I think BIERin6 would require a
draft as well for the optional IPv6 encapsulation for SRv6 environment as
well.

> Zzh> I want to point out that w/o draft-xie-bier-ipv6-mvpn, BIERv6 is not

    Gyan> In fact MVPN we all agreed is not a requirement as BIER can be
used for single tenant global table multicast GTM as well.

> Zzh> How does IP work with POS? PPP header has a proto field - a new code
> point would be assigned for BIER. That is not IPv6 specific.

    Gyan2> Jingrong’s point is that when BFRs do not use L2 Ethernet
“already defined solution” in RFC 8296, is when BIERin6 should be used is
which defined IPv6 encapsulation one hop tunnels. The MAJOR problem we have
with including an existing solution RFC 8296 L2 “Non MPLS BIER Ethernet” is
that it is existing and thus overshadows a need for for IPv6 encapsulation
and to use existing solution and as written in BIERin6 that IPv6
encapsulation is “optional”.  Why should IPv6 encapsulation be optional
with BIERin6?  The latter L2 solution has existed since Day 1.  We are
defining a new solution for IPv6 environment with BIERin6.  The case and
point here is that most operators in the last 15 years have decommissioned
all TDM based with Metro Ethernet services.  So in essence with draft
BIERin6 the way it is written IPv6 encapsulation single hop or multi hop
tunnels would never be used by operators.
So then you might as well remove IPv6 encapsulation from the draft as it’s
an option that would never be used.  Once you do that you are left with RFC
8296 use case informational draft and questionable if that is even
necessary.

The way BIERin6 is written today it would be very difficult to advance for
WG adoption.

> Zzh> *The* BIERin6 proposal is BIER over L2 and/or tunnels (IPv6 or not).
> In case of IPv6 tunnels, new code points are needed and that's why it needs
> to be on standards track, as I already explained.

    Gyan> The way it’s written IPv6 encapsulation one hop tunnels would
never be used by operators as it’s overshadowed by RFC 8296.  The way
BIERin6 reads it as L2 RFC 8296 can be used for multi hop funnels in case
of Non BFRs as well.  Even if the operator requires BIER to be carried in
IPv6 it would be doubtful that would get utilized for one hop tunnels as
it’s easier to just use RFC 8296 L2 for one hop or tunnel.  In essence the
IPV6 encapsulation would never be used by operators with BIERin6.
If you think about it BIERIn6 is by definition an oxymoron.  Reason being
is that with RFC 8296 included as part of BIERin6, BIER header is the outer
envelope encapsulation so it would be more accurate to say “BIERout6” as
IPv6 is the payload of BIER in L2 RFC 8296.  The only relevant piece that
makes sense in every way to be part of BIERin6 is “in” being the keyword
where the outer encapsulation is IPv6 and BIER is next header thus the “in”
in BIERin6.

>
> Zzh> I had also explained already, why BIERin6 needs to explicitly spell
> out using *existing* solution (concept, not code point) for IPv6 network -
> we've wasted two years on this.

    Gyan> Well hopefully we don’t waste another 2 year on BIERin6 or I
guess really should be called BIER-in-out-6.

 I am not in favor of adoption of  BIERin6 the way the draft is written
today.  We really have to remove the references to RFC 8296 to make this
draft even viable.

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 25 Nov 2020 15:34:32 +0000

It's funny. The dictator pretends to be innocent.

Tianran

--------------------------------------------------
Sent from WeLink

发件人：Greg Shepherd <[email-masked]>
收件人：Tianran Zhou <[email-masked]>
抄 送：Xiejingrong (Jingrong) <[email-masked]>;Jeffrey (Zhaohui) Zhang <[email-masked]>;BIER WG <[email-masked]>;Gyan Mishra <[email-masked]>
时 间：2020-11-25 22:45:27
主 题：Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Shep

On Tue, Nov 24, 2020 at 10:01 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Why do you want to stop valid comments and valid discussions?
I think both Gyan and Jingrong just raised the key technique points.
Bier in 6 is just a wrong solution and direction.

Tianran

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Shepherd

Thanks,
Shep

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Nov 2020 10:39:57 -0500

On Wed, Nov 25, 2020 at 10:29 AM Gyan Mishra <[email-masked]> wrote:

>
> Please see Gyan2>
>
> On Wed, Nov 25, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
>> Please see zzh> below.
>>
>> We need to know, what does *the* BIERin6 draft propose, and how does
>> *the* BIERin6 draft satisfy the bier-ipv6-requirements.
>

      Gyan2> Another clever way to look at is that BIER-in-out-6 is a way
to squash IPv6 encapsulation with smoke and mirrors as if a there is in a
pretentious way a néw solution is being developed, where in essence we are
actually quite the contrary, as this is the trickery game  “optional”
verbiage to provide a lead on “carrot” if you will that IPv6 encapsulation
is in the spec but really in all truthfulness let it be told the spec is
really BIERout6.

>> I thought about this some more and I think what creates a lot of
>> confusion in my mind with BIERin6 solution is the L2/tunnel component.
>>

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 25 Nov 2020 18:11:12 +0000

@Alvaro Retana<mailto:[email-masked]>@[email-masked]<mailto:[email-masked]> – one request below for the chair and AD.
@Xiejingrong (Jingrong)<mailto:[email-masked]> – two question/comment below.

Hi Gyan,

Please see zzh2> below.

From: Gyan Mishra <[email-masked]>
Sent: Wednesday, November 25, 2020 10:40 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: BIER WG <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>
Subject: Re: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

On Wed, Nov 25, 2020 at 10:29 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Please see Gyan2>

On Wed, Nov 25, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Please see zzh> below.

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Gyan2> BIERv6 follows RFC 8200 specification in using DOH to encode BIER for hop by hop en route processing.  MPLS BIER has an RFC 8556 for MVPN even though it follows standard MVPN procedures RFC 6513 6514.  Non MPLS BIER is not any different in that respect but also requires as in IPv6 environment uses SRv6 BGP Overlay Service.  I think BIERin6 would require a draft as well for the optional IPv6 encapsulation for SRv6 environment as well.

Zzh2> For BIERin6 with SRv6 based services, all we need is an assigned well-known multicast locator and in case of MVPN/EVPN a new PTA type/id in xPMSI. As I mentioned, we’ll add a section in BIERin6, or it can be done in a separate draft.
Zzh2> Regardless whether it is a separate draft, I was just responding to the “which is non-trivial” comment – it is certainly much simpler than the BIERv6 scheme.

    Gyan2> In fact MVPN we all agreed is not a requirement as BIER can be used for single tenant global table multicast GTM as well.

zzh2> The requirements draft lists “Supporting different multicast flow overlays” and MVPN is one of them.
Zzh2> I would request @Xiejingrong (Jingrong)<mailto:[email-masked]> to comment about “MVPN … is not a requirement as BIER can be used for single tenant global table multicast GTM as well”.

Gyan2> Jingrong’s point is that when BFRs do not use L2 Ethernet “already defined solution” in RFC 8296, is when BIERin6 should be used is which defined IPv6 encapsulation one hop tunnels. The MAJOR problem we have with including an existing solution RFC 8296 L2 “Non MPLS BIER Ethernet” is that it is existing and thus overshadows a need for for IPv6 encapsulation and to use existing solution and as written in BIERin6 that IPv6 encapsulation is “optional”.

Zzh2> We’re completely going in circles. I say it one more time – BIERin6 is about “BIER support in IPv6 Networks”, and BIER over L2 is certainly a viable and for many operators a preferred solution. Given the multi-year saga on BIERin6/BIERv6 and the heated, long/nested email threads going on now, it is even more critical to explicitly point out in the BIERin6 draft that “BIER support in IPv6 Networks” can naturally use BIER over L2 or tunnels, where tunnels can be any tunnel, IPv6 or not, one-hop or multi-hop.
Zzh2> Would like @Alvaro Retana<mailto:[email-masked]> @[email-masked]<mailto:[email-masked]> to chime in, whether it is appropriate if BIERin6, which is about “BIER support in IPv6 Networks”, to talk about BIER over L2 and tunnels. In fact, from BIER’s point of view, there is no difference between over L2 and over any kind of tunnel.

Gyan2> Why should IPv6 encapsulation be optional with BIERin6?  The latter L2 solution has existed since Day 1.  We are defining a new solution for IPv6 environment with BIERin6.

Zzh2> IPv6 encapsulation for directly connected BFRs is optional in BIERin6, because BIER over L2 w/o IPv6 encapsulation just works but we want to allow IPv6 encapsulation for some operators who demand IPv6 encapsulation even between directly connected BFRs.
Zzh2> BIERin6 is not just “defining a new solution for IPv6”. It is about specifying “how BIER can be supported for IPv6” (in one way if you want to be exact).

Gyan2> The case and point here is that most operators in the last 15 years have decommissioned all TDM based with Metro Ethernet services.
Zzh2> Then can you ask @Xiejingrong (Jingrong)<mailto:[email-masked]> why he asked about POS?

So in essence with draft BIERin6 the way it is written IPv6 encapsulation single hop or multi hop tunnels would never be used by operators.

Zzh2> It’s clear that you have not followed the discussion. Multi-hop tunneling will certainly be used, either for getting over non-BFRs or for FRR (which will be here for long term).

So then you might as well remove IPv6 encapsulation from the draft as it’s an option that would never be used.  Once you do that you are left with RFC 8296 use case informational draft and questionable if that is even necessary.

Zzh2> Wrong conclusion based on wrong assumption – see above.

The way BIERin6 is written today it would be very difficult to advance for WG adoption.

    Gyan> The way it’s written IPv6 encapsulation one hop tunnels would never be used by operators as it’s overshadowed by RFC 8296.  The way BIERin6 reads it as L2 RFC 8296 can be used for multi hop funnels in case of Non BFRs as well.  Even if the operator requires BIER to be carried in IPv6 it would be doubtful that would get utilized for one hop tunnels as it’s easier to just use RFC 8296 L2 for one hop or tunnel.  In essence the IPV6 encapsulation would never be used by operators with BIERin6.
If you think about it BIERIn6 is by definition an oxymoron.  Reason being is that with RFC 8296 included as part of BIERin6, BIER header is the outer envelope encapsulation so it would be more accurate to say “BIERout6” as IPv6 is the payload of BIER in L2 RFC 8296.  The only relevant piece that makes sense in every way to be part of BIERin6 is “in” being the keyword where the outer encapsulation is IPv6 and BIER is next header thus the “in” in BIERin6.

    Gyan> Well hopefully we don’t waste another 2 year on BIERin6 or I guess really should be called BIER-in-out-6.

      Gyan2> Another clever way to look at is that BIER-in-out-6 is a way to squash IPv6 encapsulation with smoke and mirrors as if a there is in a pretentious way a néw solution is being developed, where in essence we are actually quite the contrary, as this is the trickery game  “optional” verbiage to provide a lead on “carrot” if you will that IPv6 encapsulation is in the spec but really in all truthfulness let it be told the spec is really BIERout6.

Zzh2> The above again shows that you have not followed the discussion.
Zzh2> I’ve always said that BIERin6 is an existing solution, albeit it needs new code points, to allow BIER header following an IPv6 header.
Zzh2> Jeffrey

 I am not in favor of adoption of  BIERin6 the way the draft is written today.  We really have to remove the references to RFC 8296 to make this draft even viable.

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XgM9nZcm8mxG0SCM8QF-Qsyg3BEjUQWT5BlBYf3Y_zmD2xCvRtDyA4zikXIQZmq-$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XgM9nZcm8mxG0SCM8QF-Qsyg3BEjUQWT5BlBYf3Y_zmD2xCvRtDyA4zikXIQZmq-$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Nov 2020 15:50:58 -0500

Thank you Jeffrey and sorry for going in circles on this.  I believe this
is a very important subject so I think time well spent to iron out this
last critical point as it delves into Greg’s original question as to reason
for IPV6 encapsulation if we already have a solution.

The big question for Greg and Alvaro about the existing RFC 8296 solution
of it should be included or not in BIERin6 draft.

That has been the crux of the entire thread.

Thank you

Gyan

On Wed, Nov 25, 2020 at 1:11 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> @Alvaro Retana <[email-masked]>@[email-masked]
> <[email-masked]> – one request below for the chair and AD.
>
> @Xiejingrong (Jingrong) <[email-masked]> – two question/comment
> below.
>
>
>
> Hi Gyan,
>
>
>
> Please see zzh2> below.
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Wednesday, November 25, 2020 10:40 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* BIER WG <[email-masked]>; Xiejingrong (Jingrong) <
> [email-masked]>
> *Subject:* Re: What does BIERin6 propose to satisfy the requirements?
> //RE: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
>
>
> Gyan2> BIERv6 follows RFC 8200 specification in using DOH to encode BIER
> for hop by hop en route processing.  MPLS BIER has an RFC 8556 for MVPN
> even though it follows standard MVPN procedures RFC 6513 6514.  Non MPLS
> BIER is not any different in that respect but also requires as in IPv6
> Zzh2> For BIERin6 with SRv6 based services, all we need is an assigned
> well-known multicast locator and in case of MVPN/EVPN a new PTA type/id in
> xPMSI. As I mentioned, we’ll add a section in BIERin6, or it can be done in
> a separate draft.
>
> Zzh2> Regardless whether it is a separate draft, I was just responding to
> the “which is non-trivial” comment – it is certainly much simpler than the
> BIERv6 scheme.
>
>
>     Gyan2> In fact MVPN we all agreed is not a requirement as BIER can be
> Zzh2> I would request @Xiejingrong (Jingrong) <[email-masked]> to
> comment about “MVPN … is not a requirement as BIER can be used for single
> tenant global table multicast GTM as well”.
>
>
>
>
> Gyan2> Jingrong’s point is that when BFRs do not use L2 Ethernet “already
> defined solution” in RFC 8296, is when BIERin6 should be used is which
> defined IPv6 encapsulation one hop tunnels. The MAJOR problem we have with
> including an existing solution RFC 8296 L2 “Non MPLS BIER Ethernet” is that
> it is existing and thus overshadows a need for for IPv6 encapsulation and
> to use existing solution and as written in BIERin6 that IPv6 encapsulation
> is “optional”.
>
>
>
> Zzh2> We’re completely going in circles. I say it one more time – BIERin6
> is about “BIER support in IPv6 Networks”, and BIER over L2 is certainly a
> viable and for many operators a preferred solution. Given the multi-year
> saga on BIERin6/BIERv6 and the heated, long/nested email threads going on
> now, it is even more critical to explicitly point out in the BIERin6 draft
> that “BIER support in IPv6 Networks” can naturally use BIER over L2 or
> tunnels, where tunnels can be any tunnel, IPv6 or not, one-hop or multi-hop.
>
> Zzh2> Would like @Alvaro Retana <[email-masked]> @[email-masked]
> <[email-masked]> to chime in, whether it is appropriate if BIERin6,
> which is about “BIER support in IPv6 Networks”, to talk about BIER over L2
> and tunnels. In fact, from BIER’s point of view, there is no difference
> between over L2 and over any kind of tunnel.
>
>
>
> Gyan2> Why should IPv6 encapsulation be optional with BIERin6?  The latter
> L2 solution has existed since Day 1.  We are defining a new solution for
> IPv6 environment with BIERin6.
>
>
>
> Zzh2> IPv6 encapsulation for directly connected BFRs is optional in
> BIERin6, because BIER over L2 w/o IPv6 encapsulation just works but we want
> to allow IPv6 encapsulation for some operators who demand IPv6
> encapsulation even between directly connected BFRs.
>
> Zzh2> BIERin6 is not just “defining a new solution for IPv6”. It is about
> specifying “how BIER can be supported for IPv6” (in one way if you want to
> be exact).
>
>
>
> Gyan2> The case and point here is that most operators in the last 15 years
> have decommissioned all TDM based with Metro Ethernet services.
>
> Zzh2> Then can you ask @Xiejingrong (Jingrong) <[email-masked]>
> why he asked about POS?
>
>
>
> So in essence with draft BIERin6 the way it is written IPv6 encapsulation
> single hop or multi hop tunnels would never be used by operators.
>
>
>
> Zzh2> It’s clear that you have not followed the discussion. Multi-hop
> tunneling will certainly be used, either for getting over non-BFRs or for
> FRR (which will be here for long term).
>
>
>
> Zzh2> I’ve always said that BIERin6 is an existing solution, albeit it
> needs new code points, to allow BIER header following an IPv6 header.
>
> Zzh2> Jeffrey
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XgM9nZcm8mxG0SCM8QF-Qsyg3BEjUQWT5BlBYf3Y_zmD2xCvRtDyA4zikXIQZmq-$>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> --
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XgM9nZcm8mxG0SCM8QF-Qsyg3BEjUQWT5BlBYf3Y_zmD2xCvRtDyA4zikXIQZmq-$>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 25 Nov 2020 21:46:16 +0000

As I mentioned several times, “reason for IPV6 encapsulation” has several aspects.

  1.  Between directly connected BFRs
  2.  Between BFRs that are not directly connected (for non-BFR or FRR support)
  3.  From BFIR to BFER

#1 is optional BIERin6. #2 is used BIERin6 for non-BFR or FRR support reasons.
#3 was introduced in BIERv6 and it is what triggered Greg’s original question, and that’s the crux for adding the IPv6 encapsulation discussion to the requirements draft.

I am sure the BFIR->BFER IPv6 encapsulation requirements will be added to the requirements draft. Then it comes to a solution question – how does that work with BIER.

BIERin6 already has a solution (unspoken yet in the draft) for #3 (IPv6 becomes BIER payload) due to its nice clean layering, and it makes SRv6 based MVPN/EVPN much easier and more aligned with unicast. As a comparison, for #1 and #2, BIER header comes as IPv6 payload.

Jeffrey

From: Gyan Mishra <[email-masked]>
Sent: Wednesday, November 25, 2020 3:51 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: Re: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thank you Jeffrey and sorry for going in circles on this.  I believe this is a very important subject so I think time well spent to iron out this last critical point as it delves into Greg’s original question as to reason for IPV6 encapsulation if we already have a solution.

The big question for Greg and Alvaro about the existing RFC 8296 solution of it should be included or not in BIERin6 draft.

Thank you

Gyan

On Wed, Nov 25, 2020 at 1:11 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
@Alvaro Retana<mailto:[email-masked]>@[email-masked]<mailto:[email-masked]> – one request below for the chair and AD.
@Xiejingrong (Jingrong)<mailto:[email-masked]> – two question/comment below.

Hi Gyan,

Please see zzh2> below.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 25, 2020 10:40 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Subject: Re: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Please see Gyan2>

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyEqzmhS6$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 26 Nov 2020 02:55:55 +0000

Hi Jeffrey,

Thanks for your discussions, but the key questions here are:
What does BIERin6 propose to satisfy these requirements we have consensus on  ---- I believe it’s the “IPv6 next header / IPv4 protocol” value that is to be allocated to fill the gaps that current RFC8296 can’t satisfy. is it ?
Then the second question, Is the allocation of “IPv6 next header / IPv4 protocol” proposal an “existing solution”?
The third question, If it is an “existing solution”, where does it exist and why do you even need the BIERin6 draft ?

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, November 26, 2020 5:46 AM
To: Gyan Mishra <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: RE: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Thank you

Gyan

Hi Gyan,

Please see zzh2> below.

Please see Gyan2>

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 26 Nov 2020 03:50:04 +0000

Hi Jeffrey,

Bierv6 is a nice design. It works very well in IPv6 scenario.
Given we already have Bierv6, I do not understand why we are still arguing the requirement for Bier in 6.
I just see no need for Bier in 6.

Cheers,
Tianran

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Wednesday, November 25, 2020 10:14 PM
To: Tianran Zhou <[email-masked]>; [email-masked]; Xiejingrong (Jingrong) <[email-masked]>
Cc: BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: RE: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Hi Tianran,

Ø  Bier in 6 is just a wrong solution and direction.

Jeffrey

From: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 25, 2020 1:01 AM
To: [email-masked]<mailto:[email-masked]>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Tianran

Thanks,
Shep

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 25 Nov 2020 20:11:40 -0800

Hi Tianran,
I just recently read both proposals - BIERin6 and BIERv6. Understandably, I
was interested in how each solution handles BIER OAM.
draft-zhang-bier-bierin6 explains that:
   BIER has its own OAM function, so generally the IPv6 OAM function is
   not needed.
And I agree with that conclusion. BIER OAM will work because BIER header is
used as defined in RFC 8296, including using OAM value in the Proto field.
draft-xie-bier-ipv6-encapsulation states that:
        How BIER-PING is supported in BIERv6
        encapsulation without using this Proto field is outside the
        scope of this document.
That left me with many questions. Thus, from my point of view, BIERv6 needs
to demonstrate how BIER OAM, as defined in numerous WG drafts, works in
BIERv6 domain. Without that, I cannot compare the two proposals fairly.

Regards,
Greg

On Wed, Nov 25, 2020 at 7:50 PM Tianran Zhou <[email-masked]> wrote:

> *From:* Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
> *Sent:* Wednesday, November 25, 2020 10:14 PM
> *To:* Tianran Zhou <[email-masked]>; [email-masked];
> Xiejingrong (Jingrong) <[email-masked]>
> *Cc:* BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>
> *Subject:* RE: [Bier] What does BIERin6 propose to satisfy the
> *From:* Tianran Zhou <[email-masked]>
> *Sent:* Wednesday, November 25, 2020 1:01 AM
> *To:* [email-masked]; Xiejingrong (Jingrong) <[email-masked]>
> *Subject:* RE: [Bier] What does BIERin6 propose to satisfy the
> *From:* BIER [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Greg Shepherd
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Si-OI7n2KWZpZrAUn6G14gDTm6ICWah6GxBVRm00DTGFWCb0rs1cnBoFCUdkIsCQ$>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Nov 2020 23:39:02 -0500

Hi Greg

I am going to start a new a new thread on this OAM topic so folks don’t get
confuse the OAM topic which is important as well with this contentious
requirements draft topic related to why underlying question as to why we
need IPv6 encapsulation to carry BIER as we have a solution that works
today with RFC 8296 Non MPLS BIER Ethernet next header 0xAB37 as well as
topic related to why we need BIERin6 as the L2 solution to carry IPv6
payload  is in RFC 8296.

Thanks

Gyan

This thread and the other requirements draft that have been ongoing since
the

On Wed, Nov 25, 2020 at 11:11 PM Greg Mirsky <[email-masked]> wrote:

> Hi Tianran,
> I just recently read both proposals - BIERin6 and BIERv6. Understandably,
> I was interested in how each solution handles BIER OAM.
> And I agree with that conclusion. BIER OAM will work because BIER header
> is used as defined in RFC 8296, including using OAM value in the Proto
> field.
> That left me with many questions. Thus, from my point of view, BIERv6
> needs to demonstrate how BIER OAM, as defined in numerous WG drafts, works
> in BIERv6 domain. Without that, I cannot compare the two proposals fairly.
>
> Regards,
> Greg
>
>
>> *Cc:* Jeffrey (Zhaohui) Zhang <[email-masked]>; BIER WG <
>> [email-masked]>; Gyan Mishra <[email-masked]>
>> *Cc:* Jeffrey (Zhaohui) Zhang <[email-masked]>; BIER WG <
>> [email-masked]>; Gyan Mishra <[email-masked]>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Nov 2020 02:26:34 -0500

Jeffrey

In-line Gyan>

On Wed, Nov 25, 2020 at 4:46 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

>  Gyan> #1 and #2 can be done with RFC 8296 Non MPLS BIER Ethernet.  Only
> FRR might need BIERin6, however for FRR local protection to work with L2
> tunnel for PLR bypass can be done.
>

The other requirement for BIERin6 is if operators requires IPV6
encapsulation, well now the encapsulation does exist but in the payload
technically with L2, and so even then BIERIn6 “optional” solution would not
be used.

The fact that BIERin6 always has to be qualified as “optional” solution it
basically would be non existent and would not be deployed by operators.

>    So then as stated as BIERin6 is optional and as long as BFR uses
Ethernet, then all of the above can be accomplished today with “L2” RFC
8296 Non MPLS BIER.  My point is the optional BIERin6 as it is optional
**not recommended** basically would never be used.

For the last 15 years TDM had been eliminated from carrier networks and MEF
MetroE is really the only L2 medium  for carrier handoff.  So the idea that
BIERin6 would be used for non Ethernet scenario as that scenario does not
exist it would not happen as well.

> #3 was introduced in BIERv6 and it is what triggered Greg’s original
> question, and that’s the crux for adding the IPv6 encapsulation discussion
> to the requirements draft.
>
>
>
> I am sure the BFIR->BFER IPv6 encapsulation requirements will be added to
> the requirements draft. Then it comes to a solution question – how does
> that work with BIER.
>
>
>
> BIERin6 already has a solution (unspoken yet in the draft) for #3 (IPv6
> becomes BIER payload) due to its nice clean layering, and it makes SRv6
> based MVPN/EVPN much easier and more aligned with unicast. As a comparison,
> for #1 and #2, BIER header comes as IPv6 payload.
>
>  Gyan> That unspoken solution is “L2” RFC 8296 Non MPLS Bier Ethernet
> where IPv6 is the payload of BIER.   So then as you stated clearly why do
> we need a BIERin6 draft?
>
    The main point here that I have mentioned several times is that the
“optional” BIERin6 solution would never be used as it is overshadowed by
the    “existing “ solution which is hush hush unspoken “L2 one hop or
multi hop RFC 8296” solution.  What this does is also overshadow BIERv6 as
well as the playing field is not level as now RFC 8296 Non MPLS BIER
Ethernet L2 solution becomes the ubiquitous dominant solution for IPV6
environments.

The only way for IPv6 encapsulation solution both BIERin6 or BIERv6 that
Greg referred to as the “why do we need IPv6 encapsulation” is if the L3
RFC 8296 Non MPLS BIER Ethernet  next header 0xAB37 is removed from the
BIERin6 draft.

> *Sent:* Wednesday, November 25, 2020 3:51 PM
> *Cc:* Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>;
> Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
> On Wed, Nov 25, 2020 at 1:11 PM Jeffrey (Zhaohui) Zhang <
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
>
>
>
> --
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyMEHJjID$>
>
>
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SS2YlPK0PoO2UO-PtUbsIzC4Wy4-S0FXns06s8B7zNgCVbVz1OmGwrhPyEqzmhS6$>
>
> *Gyan Mishra*
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
-- 

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Nov 2020 12:15:04 +0000

Hi Jingrong,

Please see zzh> below.

From: Xiejingrong (Jingrong) <[email-masked]>
Sent: Wednesday, November 25, 2020 9:56 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: RE: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffrey,

Zzh> Yes.

Zzh> It’s an existing solution that needs a new code point to run on IPv6 tunnels. If you have to split hair like this, I will indulge you by calling it RFC8296 solution with new code points.
Zzh> Pretend for a moment, that MPLS folks would decide to add a way to indicate the payload type and a code point is allocated for IPv4/v6. Would that make IPv4/v6 a “new” solution? Or would you call IPv4/v6 an “existing” solution?

Zzh> I have said this *many* times:
Zzh> 1. To allocate new code points, standards track document is needed.
Zzh> 2. The multi-year saga on BIERin6/BIERv6 and this long contentious discussion have made it super clear that we need a draft to explicitly call out that existing RFC8296 solution can be used for IPv6 networks nicely after the allocation of new code points.
Zzh> Jeffrey

Thanks
Jingrong

To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>

Jeffrey

Thank you

Gyan

Hi Gyan,

Please see zzh2> below.

Please see Gyan2>

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Nov 2020 12:20:27 +0000

Hi Tianran,

I did not see your argument why BIERin6 is “just a wrong solution and direction”.

Additionally, BIERin6 is existing RFC8296 solution with a new code point. Both from solution history and document timeline, BIERin6 comes *before* BIERv6 and it works with a nice clean layering. BIERv6 on the other hand has its issues (will expand on those in separate threads).

Therefore, the question should be flipped around – why BIERv6?

Jeffrey

From: Tianran Zhou <[email-masked]>
Sent: Wednesday, November 25, 2020 10:50 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; Xiejingrong (Jingrong) <[email-masked]>
Cc: BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: RE: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffrey,

Cheers,
Tianran

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Wednesday, November 25, 2020 10:14 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Hi Tianran,

Jeffrey

Tianran

Thanks,
Shep

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 26 Nov 2020 12:30:56 +0000

Let me disagree with that.
1. Allocation of a new IPv6 next header / IPv4 protocol is not “existing” solution. It never exists, nor does it explain why need it.
2. The BIER IPv6 work does not include existing RFC8296 ---- BIER MPLS or BIER ETH.  Have been clarified by Alia.

BTW: Does BIERin6 still need MPLS Label for MVPN ? That is not an Non-MPLS solution.

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, November 26, 2020 8:15 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: RE: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Hi Jingrong,

Please see zzh> below.

To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>

Hi Jeffrey,

Zzh> Yes.

Thanks
Jingrong

Jeffrey

Thank you

Gyan

Hi Gyan,

Please see zzh2> below.

Please see Gyan2>

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Nov 2020 12:55:30 +0000

Hi Gyan,

I have to say again that we’re going in circles. For example (there are more examples below), in this thread you asked again “why do we need a BIERin6 draft”? Let me answer that for the *fourth* time:

1. To allocate new code points, standards track document is needed.
2. The multi-year saga on BIERin6/BIERv6 and this long contentious discussion have made it super clear that we need a draft to explicitly call out that existing RFC8296 solution can be used for IPv6 networks nicely after the allocation of new code points.

More zzh> below.

Sent: Thursday, November 26, 2020 2:27 AM

Jeffrey

In-line Gyan>

On Wed, Nov 25, 2020 at 4:46 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
As I mentioned several times, “reason for IPV6 encapsulation” has several aspects.

  1.  Between directly connected BFRs
  2.  Between BFRs that are not directly connected (for non-BFR or FRR support)
  3.  From BFIR to BFER
 Gyan> #1 and #2 can be done with RFC 8296 Non MPLS BIER Ethernet.  Only FRR might need BIERin6, however for FRR local protection to work with L2 tunnel for PLR bypass can be done.
Zzh> As I said *many* times, only IPv6 encapsulation for #1 is *optional* and only for specific scenarios. For #2 with FRR, as long as tunneling is needed to achieve protection, then IPv6 encapsulation becomes necessary (if you don’t want to use other types of tunnels).

The other requirement for BIERin6 is if operators requires IPV6 encapsulation, well now the encapsulation does exist but in the payload technically with L2, and so even then BIERIn6 “optional” solution would not be used.

Zzh> In the above paragraph, are you referring to #1 or #3?

The fact that BIERin6 always has to be qualified as “optional” solution it basically would be non existent and would not be deployed by operators.

Zzh> This is why I say again and again that we’re going in circles. Please stop.
Zzh> Only “BIER with one-hop IPv6 encapsulation” is optional *!!!!!!*

   So then as stated as BIERin6 is optional and as long as BFR uses Ethernet, then all of the above can be accomplished today with “L2” RFC 8296 Non MPLS BIER.  My point is the optional BIERin6 as it is optional **not recommended** basically would never be used.

Zzh> Please see above *!!!!!*

For the last 15 years TDM had been eliminated from carrier networks and MEF MetroE is really the only L2 medium  for carrier handoff.  So the idea that BIERin6 would be used for non Ethernet scenario as that scenario does not exist it would not happen as well.

Zzh> That is an argument against Jingrong’ POS comment.
#1 is optional BIERin6. #2 is used BIERin6 for non-BFR or FRR support reasons.
#3 was introduced in BIERv6 and it is what triggered Greg’s original question, and that’s the crux for adding the IPv6 encapsulation discussion to the requirements draft.

BIERin6 already has a solution (unspoken yet in the draft) for #3 (IPv6 becomes BIER payload) due to its nice clean layering, and it makes SRv6 based MVPN/EVPN much easier and more aligned with unicast. As a comparison, for #1 and #2, BIER header comes as IPv6 payload.
 Gyan> That unspoken solution is “L2” RFC 8296 Non MPLS Bier Ethernet where IPv6 is the payload of BIER.   So then as you stated clearly why do we need a BIERin6 draft?
Zzh> Please see my response – for the fourth time – at the beginning of this email.
The main point here that I have mentioned several times is that the “optional” BIERin6 solution would never be used as it is overshadowed by the    “existing “ solution which is hush hush unspoken “L2 one hop or multi hop RFC 8296” solution.  What this does is also overshadow BIERv6 as well as the playing field is not level as now RFC 8296 Non MPLS BIER Ethernet L2 solution becomes the ubiquitous dominant solution for IPV6 environments.

Zzh> BIERin6, which is existing RFC8296 solution with new code points, already works nicely for IPv6 environments with clean layering. As such, documenting it as the base (or “first”) solution is quite natural and reasonable.
Zzh> BIERv6, which is a new (or “second”) solution, is subject to WG discussions (just as with BIERin6) and there have been quite some exchanges about its issues, both online and offline. I will send out more about related BIER-MVPN solution.
Zzh> If BIERin6 solution does become ubiquitous dominant, then great (to many of us) – but saying it “overshadows” BIERv6 now just shows lack of confidence for BIERv6.
Zzh> Jeffrey

The only way for IPv6 encapsulation solution both BIERin6 or BIERv6 that Greg referred to as the “why do we need IPv6 encapsulation” is if the L3 RFC 8296 Non MPLS BIER Ethernet  next header 0xAB37 is removed from the BIERin6 draft.
Jeffrey

Thank you

Gyan

Hi Gyan,

Please see zzh2> below.

Please see Gyan2>

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!TPhFsPpq4c8GQyx9qlPxqYft37Cjn_rpBcw7gjMBRuNCUe72C_DtOIiQYxSoB-9r$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!TPhFsPpq4c8GQyx9qlPxqYft37Cjn_rpBcw7gjMBRuNCUe72C_DtOIiQYz8Yw57M$>

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TPhFsPpq4c8GQyx9qlPxqYft37Cjn_rpBcw7gjMBRuNCUe72C_DtOIiQYzApbqIt$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Nov 2020 13:09:02 +0000

Please see zzh2> below.

Sent: Thursday, November 26, 2020 7:31 AM

Zzh2> Fine if you want to split hair like this. I’ve already started referring to BIERin6 as RFC8296 with new code points.

Zzh2> If I understand you correctly where you are going, what Alia said is not that 8296 solutions cannot be used for IPv6 networks. Rather, it is that the WG *can* work on new solutions. Nobody is saying that we should not work on BIERv6. I am just saying that BIERv6 is not necessary (and with issues), but of course that is subject to WG discussion, and should not block the progress of BIERin6.

Zzh2> If you have *really* followed my discussions, you will know that BIERin6 can work w/ or w/o MPLS service labels.
Zzh2> I had pointed out issues with draft-xie-bier-ipv6-mvpn before and recently had an offline exchange with Gyan on top of that old email thread. I will bring that offline discussion to the mailing list after I put my turkey in the oven.
Zzh2> Jeffrey

Thanks
Jingrong

To: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>

Hi Jingrong,

Please see zzh> below.

Hi Jeffrey,

Zzh> Yes.

Thanks
Jingrong

Jeffrey

Thank you

Gyan

Hi Gyan,

Please see zzh2> below.

Please see Gyan2>

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Nov 2020 12:14:03 -0500

Hi Jeffrey and  All,

Happy Thanksgiving for those celebrating!!

Please enjoy this time with your family and be safe!!

Hi Jeffrey

Thank you for your patience on this long enduring nested thread.

I think we both have stated our points numerous times.  At this point we
are not making any further progress discussing this topic.

As you stated on the other email thread and you are correct and we are in
sync on that point that the  main contention point is having L2 RFC 8296
Non MPLS BIER Ethernet included in the BIERin6 draft.

Let’s wait for Greg Shepherd & Alvaro to make the final decision.

I am all set on my end and I will end my discussion of this topic.

Kind Regards

Gyan

On Thu, Nov 26, 2020 at 7:55 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Gyan,
>
>
>
> I have to say again that we’re going in circles. For example (there are
> more examples below), in this thread you asked again “why do we need a
> BIERin6 draft”? Let me answer that for the **fourth** time:
>
>
>
> 2. The multi-year saga on BIERin6/BIERv6 and this long contentious
> discussion have made it super clear that we need a draft to explicitly call
> out that existing RFC8296 solution can be used for IPv6 networks nicely
> after the allocation of new code points.
>
>
>
> More zzh> below.
>
>
>
> *Sent:* Thursday, November 26, 2020 2:27 AM
> On Wed, Nov 25, 2020 at 4:46 PM Jeffrey (Zhaohui) Zhang <
> Zzh> As I said **many** times, only IPv6 encapsulation for #1 is *
> *optional** and only for specific scenarios. For #2 with FRR, as long as
> tunneling is needed to achieve protection, then IPv6 encapsulation becomes
> necessary (if you don’t want to use other types of tunnels).
>
>
>
> For the last 15 years TDM had been eliminated from carrier networks and
> MEF MetroE is really the only L2 medium  for carrier handoff.  So the idea
> that BIERin6 would be used for non Ethernet scenario as that scenario does
> not exist it would not happen as well.
>
>
>
> Zzh> BIERin6, which is existing RFC8296 solution with new code points,
> already works nicely for IPv6 environments with clean layering. As such,
> documenting it as the base (or “first”) solution is quite natural and
> reasonable.
>
> Zzh> BIERv6, which is a new (or “second”) solution, is subject to WG
> discussions (just as with BIERin6) and there have been quite some exchanges
> about its issues, both online and offline. I will send out more about
> related BIER-MVPN solution.
>
> Zzh> If BIERin6 solution does become ubiquitous dominant, then great (to
> many of us) – but saying it “overshadows” BIERv6 now just shows lack of
> confidence for BIERv6.
>
> Zzh> Jeffrey
>
>
>
> <https://www.google.com/maps/search/13101+Columbia%0D%0A+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> <https://www.google.com/maps/search/13101+Columbia%0D%0A+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> *Gyan Mishra*
>
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!TPhFsPpq4c8GQyx9qlPxqYft37Cjn_rpBcw7gjMBRuNCUe72C_DtOIiQYxSoB-9r$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!TPhFsPpq4c8GQyx9qlPxqYft37Cjn_rpBcw7gjMBRuNCUe72C_DtOIiQYz8Yw57M$>
>
>
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TPhFsPpq4c8GQyx9qlPxqYft37Cjn_rpBcw7gjMBRuNCUe72C_DtOIiQYzApbqIt$>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 27 Nov 2020 02:38:34 +0000

Hi Gyan, Jeffrey, all,

I agree with Gyan, and I will end my discussion of this topic ---- a non-Ethernet link case as an example of Req-1.

Also both have stated out points numerous times:

BIERin6 claims it can satisfy this Req-1 but propose to use an allocation of IPv6 next header / IPv4 protocol code point.

In my opinion (and I believe many others), the allocation of IPv6 next header / IPv4 protocol is not the “existing” thing.

Jeffrey has some other concerns about the Req-2 MVPN/EVPN things, I too have concerns about MVPN/EVPN things in BIERin6.

So I will move to that topic.

Thanks
Jingrong

Sent: Friday, November 27, 2020 1:14 AM

Hi Jeffrey and  All,

Hi Jeffrey

I think we both have stated our points numerous times.  At this point we are not making any further progress discussing this topic.

As you stated on the other email thread and you are correct and we are in sync on that point that the  main contention point is having L2 RFC 8296 Non MPLS BIER Ethernet included in the BIERin6 draft.

Kind Regards

Gyan

On Thu, Nov 26, 2020 at 7:55 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

More zzh> below.

Jeffrey

In-line Gyan>

Thank you

Gyan

Hi Gyan,

Please see zzh2> below.

Please see Gyan2>

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 24, 2020 10:27 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

Thanks
Jingrong

-----Original Message-----
From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 25, 2020 9:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Jeffrey

Kind Regards

Gyan

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
Silver Spring, MD<https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD