Re: [Bier] BIERv6 and BIERin6 support of MVPN-EVPN (bier-ipv6-requirements REQ-2) //FW: draft-xie-bier-ipv6-mvpn question:

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jingrong,

Does BIERv6-MVPN require different func/arg values for unicast and multicast, even for the same VPN?
Otherwise I can't understand how R5 can send R1 unicast VPN traffic using Loc1:100 and receive multicast VPN traffic from R1 using Loc1:100 and use the same table.

Thanks.
Jeffrey

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]>
Sent: Friday, November 27, 2020 11:43 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: BIERv6 and BIERin6 support of MVPN-EVPN (bier-ipv6-requirements REQ-2) //FW: draft-xie-bier-ipv6-mvpn question:

[External Email. Be cautious of content]


Hi Jeffrey,

Hope we don't have to repeat that much numerous times as previous topic, so I will summary the stated out points on BIERin6-MVPN/EVPN.

--------Your point--------:
BIER is really "L2 header + BIER header + V6 header + payload which could be v4/6".

--------My understanding to your point--------:
VXLAN-NVGRE-GENEVE could be used before payload as VPN identifying, or VXLAN-NVGRE-GENEVE could be not used before Payload and Destination address FUNC/ARG in the V6 header could be used as VPN identifying.

--------My point to the weakness of BIERin6-MVPN solution--------:
When combining with BIERin6 (for Non-Ethernet link, or for anything you need an IPv6 tunnel before BIER header):
It need [IPv6 tunnel header] + BIER header + V6 header [+vxlan/nvgre/geneve optionally] + Customer-packet which could be v4/v6.
It costs 1 BIER header + 2 IPv6 headers (at least) to encapsulate the Customer-packet which could be v4/v6.
It is non-professional and it doesn't work except in theory/paper, and I guess anyone won't implement it due to the cost obviously.
It is not an existing solution as you described similar to MPLS.



Then I speak for the BIERv6-MVPN/EVPN solution:
"IPv6 header + DoH(with BIER header as an "Option" in it) + Customer-packet which could be v4/v6". That's all we needed from encapsulation standpoint.



Regarding the first one question you mentioned about using src address to identify the VPNs in BIERv6, there is some wrong understanding in your question.
Please see below my explanation below based on the proof of implementation (to make answer clean, I copy the question and the context here to answer in detail).

1. On the egress, when you use the src address to do the lookup, you need a separate routing table, not the existing unicast table for it. I understand that one could argue that is ok. In addition, if a BFR in the middle somehow needs to send an ICMP back to the BFIR, would the src.DT4, src.DT6, src.DT46 in the original IPv6/BIER packet, now used as destination address of the ICMP packet, cause trouble on BFIR (would it be treated as a customer packet for the VPN)?

[XJR]No, it is not a separate routing table, but an Exact-Match(EM) lookup. Exactly the same as BIER-MPLS, using { BIFT-id(representing the SD) + BFIR-id(representing the Ingress PE) + Vpn Label } for the lookup.

Zzh> It does not seem that we're understanding each other. Let me rephrase.
Zzh> Consider routers R1~R5 where R1/R5 are BFIR/BFER, Loc1~Loc5 are locators of R1~R5 (assuming /48), and for vpn100 the func/arg portion of the SRv6 address is 100.
Zzh> On R1, there is a Loc1:100 host route with END.DTx and on other routers there is a Loc1/48 route to route towards R1. On R5 there is a Loc5:100 host route with END.DTx and on other routers there is a Loc5/48 route to route towards R5.
Zzh> For unicast VPN traffic from a CE1 off R1 to a CE5 off R5, the destination address that R1 uses is Loc5:100 and when R5 gets the packet, the host route is matched and traffic is then routed in the VRF for the VPN.
Zzh> With BIER-SRv6, for multicast vpn traffic from CE1, I take it that the source address that R1 uses is Loc1:100. Now I have two questions:
Zzh> 1. If R2 needs to send an ICMP packet as a result, would it use Loc1:100 as the destination address? If yes, when it gets to R1, would it match the Loc1:100 host route and treated as a packet for the VPN?
[XJR2] The ICMP packet would use Loc1:100 as the destination address, But the packet back to R1 with destination address Loc1:100 will not be treated as a packet from the VPN.
See https://urldefense.com/v3/__https://tools.ietf.org/html/draft-xie-bier-ipv6-mvpn-03*section-6.1__;Iw!!NEt6yMaO-gk!U3mKY9Q-ex6QDvv0051OSM3LsozC1kz9hj9RKc201Fxg23Z9LLp_kCOouc87lAw3$
Only on Egress PE(R5), when it receives a X-PMSI A-D route with a Prefix-SID attribute that carris this Loc1:100 address from R1, it populate this Loc1:100 address with its local VPN100 (through the RT of the X-PMSI A-D route), and install the "lookup of (Loc1:100, VPN100)" on R5.

Zzh> 2. When R5 gets the BIER packet, after decapsulating BIER header, would it use Loc1:100 to look up the IPv6 forwarding table to determine how to forward the packet? If yes, would the packet be sent back to R1 because of the Loc1/48 route?
[XJR2] R5 use the Loc1:100 in the packet source address to execute the " lookup of (Loc1:100, VPN100)" above, and get the information that this packet is belonging to VPN100, and then forwarding the packet to this VPN. The packet won't be sent back to R1.
[XJR2] The wrong understanding in your question is that, you think the "lookup of (Loc1:100, VPN100)" is "a separate routing table" in R5. As my previous answer, it is not a separate routing table (means "Longest-Match lookup" or FIB), but an separate "Exact-Match lookup".

Thanks, and good night!
Jingrong


-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Saturday, November 28, 2020 11:06 AM
To: Xiejingrong (Jingrong) <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: BIERv6 and BIERin6 support of MVPN-EVPN (bier-ipv6-requirements REQ-2) //FW: draft-xie-bier-ipv6-mvpn question:

Hi Jingrong,

I see you only responded to the last point.
Does that mean you agree to other points, *especially* the first one about using src address to identify the VPNs?

Please see zzh2> below for my refute to your incorrect comments to that last point.

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]>
Sent: Friday, November 27, 2020 8:54 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: BIERv6 and BIERin6 support of MVPN-EVPN (bier-ipv6-requirements REQ-2) //FW: draft-xie-bier-ipv6-mvpn question:

[External Email. Be cautious of content]


Zzh> In current BIER-EVPN draft, vxlan/nvgre/geneve is mentioned only because vxlan/nvgre/geneve can be used for EVPN and BIER-EVPN works with them the same as how BIERin6 work with SRv6 - please see detailed explanation below.
Zzh> First let's forget about SRv6 for one moment - because BIER-EVPN with vxlan/nvgre/geneve does not need to involve SRv6 at all.
Zzh> Ingress PE1 gets a packet from the CE and it puts on a vxlan/nvgre/geneve header with VPN-identifying information embedded. That header is then put into an IPv4/v6 header, and then the entire IPv4/v6 header is treated as BIER payload. This is no different from the MPLS case - the service label comes after the BIER header.

So, now PE1 have a packet like this: [BIER header] [IPv6 header] [vxlan/nvgre/geneve (VPN-identify)] [Customer-Pkt(from CE)].
Remind that, the Customer-Pkt has its own IPv4/IPv6 header, and Before BIER Header you have another IPv6 header.
You are doing BIERin6 + BIERout6(or 6inBIER) + Original46 !
It is not a professional proposal with due expertise, and It doesn't work except in theory/paper.
And again that is not an "existing" solution.

Zzh2> Please note, this is when VXLAN/NVGRE/GENEVE encapsulation has to be used, which means we are not adding *any* overhead by BIERin6. Specifically, your wording "BIERin6 + BIERout6(or 6inBIER) + Original46" is completely wrong - it is really "L2 header + BIER header + V6 header + payload which could be v4/6". With BIERv6, the BIER header is encoded in the v6 header but otherwise the total header size is (roughly) the same!
Zzh2> It is an "existing" solution because, when BIER is not used, the "v6 header + Original customer payload" is how EVPN-VXLAN/NVGRE/GENEVE works and when you use BIER to transport it, you treat "v6 header + payload" as BIER payload - how is that not "existing" solution?
Zzh2> Please stop making up terms like BIERout6/6inBIER - BIERin6 simply means "supporting BIER in IPv6 using BIER over L2/tunnel". Depending on the situation, IPv6 or BIER could be the payload of the other, and that is still "BIERin6". Specifically, when BIER needs to be transported over an IPv6 tunnel, BIER is IPV6's payload (but that's not the reason for the term "BIERin6"); and when IPv6 needs to be transported by BIER (e.g. VXLAN/NVGRE/GENEVE or SRv6), then IPv6 is BIER's payload.

Zzh> Now bring SRv6 in the picture. It is actually no different from vxlan/nvgre/geneve except that the VPN-identifying information is now part of the address. With BIERin6 for SRv6 based MVPN/EVPN/service, the IPv6 packet becomes the BIER payload.
Zzh> In the BIER-EVPN draft, a well-known multicast address is requested from IANA. A single well-know multicast address can be used for both SRv6 and vxlan/nvgre/geneve - that address has Locator:FUNC:arg parts, and FUNC:arg will be 0:0 for vxlan/nvgre/geneve.

So, now you have another opinion, using the Destination address of the above "BIERout6 (or 6inBIER)" part for an SRv6-Locator-FUNC-arg structure.
I didn't see it in any BIERin6 draft or the BIER-EVPN draft [1].
And again twice it is not an "existing" solution!

Zzh2> I was just pointing out that, if an operator does want to use SRv6 based MVPN/EVPN, then just have the ingress PE put on the SRv6 header, w/ or w/o fragmentation/ESP (exactly like how it is done for unicast except a multicast locator is used), and then hand it over to BIER as BIER payload. Now to BIER, how is that not "existing" solution since BIER is transporting payload which happens to be SRv6, using BIER over L2/tunnel?
Zzh> I did acknowledge that we'll spell out details either in BIERin6 draft or in a separate draft. A new PTA may be needed, but that's on the overlay part, while the underlay is the "existing" solution, and overlay part is well aligned with unicast, unlike BIERv6-MVPN.
Zzh> Jeffrey

[1] https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-bier-evpn-03*section-4.1.1__;Iw!!NEt6yMaO-gk!Uwx9CJoJLJW3LEQKgQi8GtosTH1OsgLZM6Z9DYHLzPy7te-ZMBT8TenFnVVbpt3I$
   The "Proto" field in the BIER header is set to 2 in case of EVPN-MPLS,
   or a value to be assigned in case of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when IP header is not used,
   or 4/6 if IP header is used for EVPN-VXLAN/NVGRE/GENEVE.

Thanks
Jingrong


-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Friday, November 27, 2020 10:27 PM
To: Xiejingrong (Jingrong) <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: BIERv6 and BIERin6 support of MVPN-EVPN (bier-ipv6-requirements REQ-2) //FW: draft-xie-bier-ipv6-mvpn question:

Hi Jingrong,

Please see zzh> below.

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]>
Sent: Thursday, November 26, 2020 10:35 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BIER WG <[e-mail]>
Subject: BIERv6 and BIERin6 support of MVPN-EVPN (bier-ipv6-requirements REQ-2) //FW: draft-xie-bier-ipv6-mvpn question:

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for raising this topic.

Please see my comment below (both the question to BIERv6, and the question to BIERin6):
(I add some text to reflect both BIERv6 and BIERin6 in the topic).

Take care of life and Happy Thanksgiving! No hurry and these discussions can be done smoothly.

Thanks
Jingrong


-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Thursday, November 26, 2020 11:07 PM
To: BIER WG <[e-mail]>; Xiejingrong (Jingrong) <[e-mail]>
Subject: RE: draft-xie-bier-ipv6-mvpn question:

Happy Thanksgiving (to those who celebrate this holiday)!
Now that my turkey is roasting in oven let me continue with the discussion.

-------

Reviving this old thread that I had with Jingrong on the BIER mailing list some time ago. I see that a new revision was posted recently, but it does not address the points below.

There are three main issues with BIERv6+MVPN solution. The last two below were already mentioned in the old thread.

1. On the egress, when you use the src address to do the lookup, you need a separate routing table, not the existing unicast table for it. I understand that one could argue that is ok. In addition, if a BFR in the middle somehow needs to send an ICMP back to the BFIR, would the src.DT4, src.DT6, src.DT46 in the original IPv6/BIER packet, now used as destination address of the ICMP packet, cause trouble on BFIR (would it be treated as a customer packet for the VPN)?

[XJR]No, it is not a separate routing table, but an Exact-Match(EM) lookup. Exactly the same as BIER-MPLS, using { BIFT-id(representing the SD) + BFIR-id(representing the Ingress PE) + Vpn Label } for the lookup.

Zzh> It does not seem that we're understanding each other. Let me rephrase.
Zzh> Consider routers R1~R5 where R1/R5 are BFIR/BFER, Loc1~Loc5 are locators of R1~R5 (assuming /48), and for vpn100 the func/arg portion of the SRv6 address is 100.
Zzh> On R1, there is a Loc1:100 host route with END.DTx and on other routers there is a Loc1/48 route to route towards R1. On R5 there is a Loc5:100 host route with END.DTx and on other routers there is a Loc5/48 route to route towards R5.
Zzh> For unicast VPN traffic from a CE1 off R1 to a CE5 off R5, the destination address that R1 uses is Loc5:100 and when R5 gets the packet, the host route is matched and traffic is then routed in the VRF for the VPN.
Zzh> With BIER-SRv6, for multicast vpn traffic from CE1, I take it that the source address that R1 uses is Loc1:100. Now I have two questions:
Zzh> 1. If R2 needs to send an ICMP packet as a result, would it use Loc1:100 as the destination address? If yes, when it gets to R1, would it match the Loc1:100 host route and treated as a packet for the VPN?
Zzh> 2. When R5 gets the BIER packet,  after decapsulating BIER header, would it use Loc1:100 to look up the IPv6 forwarding table to determine how to forward the packet? If yes, would the packet be sent back to R1 because of the Loc1/48 route?

Zzh> For #2, my understanding is that R5 needs to have a *separate* table in which to look up Loc1:100.

2. To address scaling problem described in draft-ietf-bess-mvpn-evpn-aggregation-label (and earlier in this thread), you have to use a common function/arg part in different source addresses, and when doing the lookup, you have to extract that function/arg part out to do the lookup (instead of using the whole address as in unicast case). Now that is not much different from using MPLS label (for service only, not for transportation).

[XJR]We don't live in the concept of transportation/service or the like. It just works fine. IMO it's better to use ARG part though, and SRv6-NET-PGM Arg.FE2 gives a good example.

Zzh> I am not following you.
Zzh> In the previous example, 100 is agreed to be the common function/arg part, similar to an MPLS label. With SRv6, if you use the entire address for lookup, you'll need to repeat the LocX:100 route (for each PE) in that separate table. If you only use the func/arg part for lookup, you only need one route and my point is that the concept is then no different from MPLS.

3. In case segmentation is needed (which I believe will be quite common - when you have a large BIER domain with say thousands of BFERs), this draft does not provide a solution (yet).

[XJR]No, It has a complete solution, no difference than other segmentation solutions.
Zzh> In previous versions, the draft says segmentation is out of scope. In -03, that "out of scope" wording is removed, without any text describing how segmentation works. I would like to see it described.

For #3, with BIER-MPLS, when the segmentation point, which is a BFER in the upstream sub-domain, removes the BIER header, it'll see an MPLS service label for stitching  purpose - it swaps the label to a new service label associated with the PMSI, and impose a new BIER header for the downstream sub-domain (it's a BFIR in the downstream sub-domain). An alternative, which is not desired in my view, is not to use label stitching but do IP lookup in VRFs that is not needed in label stitching solution. This is discussed in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-bess-mvpn-evpn-segmented-forwarding-00__;!!NEt6yMaO-gk!XH_w__EPYPW_iJzpPT94gqLbi9Ly-90eiC-KMK71UEuMxpyChiq6KeKhdKV-UqYm$ .

[XJR] It is an "implementary" problem.
When Eric Rosen design the BIER-MVPN RFC8556, he prefers a per-flow MPLS label to simplify the "lookup" procedure, but does not simplify the re-encapsulation of NEW-BIER header.

Zzh> How does it complicate the encapsulation of NEW-BIER header (if that is what you imply)?

[XJR ] It costs much in control-plane accordingly, and worsen the performance like Multicast (S,G) join latency.
It can be "implemented" otherwise, using "per-VPN" label too, without any new control-plane needed, and I would prefer this one.

Zzh> The pros and cons are discussed in that draft.
Zzh> An operator will have to decide which way he'd prefer:
Zzh> a) at a segmentation point, maintain a VRF for each VPN. Pop the BIER header, do IP lookup and then encapsulate NEW-BIER header. The granularity of lookup is (c-s, c-g).
Zzh> b) No VRFs on segmentation point. Pop the BIER header, do mpls label swap and then encapsulate NEW-BIER header. The granularity of look up is label (which is at most per PMSI and a PMSI can aggregate a lot of (c-s,c-g).

zzh> The only small "con" for b) is that there is a bit more control plane signaling, but it comes with big savings and performance improvement in forwarding plane.

Now come back to BIERv6. When segmentation is needed, you'll either have to do IP lookup, or use the func/arg part of the source address to do "stitching", which is really just reinventing the MPLS wheel.

[XJR] BIERv6 can do either of the above "implementation", by using a per-flow Src.DT address, or per-VPN Src.DT address. No additional control-plane seen except the current draft.
Zzh> As I said before, BIERv6 and BIERv6-MPLS can be made work. It is just that it either comes with additional overhead/complexity or reinvents MPLS.

In summary, while BIERv6's BFIR->BFER encapsulation seemingly gives you parity with SRv6 based VPN solution, it actually deviates from SRv6 VPN unicast model significantly, and possible optimizations end up as reinventing the MPLS wheel.

[XJR] This is not a directly technical argument, but I like this open discussion too. BIERv6-VPN solution is some SRv6-VPN like design, it is also an evolution of MPLS wheel. But it is made as a "Non-MPLS" solution specifically in IPv6.

Zzh> As I mentioned several times, BIERin6 can work nicely with SRv6 (non-MPLS) as well w/o any additional changes (besides perhaps a new PTA, which is needed for BIERv6 as well).

I can understand that some operators want to move away from MPLS transport, but I still think MPLS based solutions for services are superior when it comes to multicast.

[XJR] This is not a directly technical argument, but I like this open discussion too.
Yes, a pure MPLS solution is wonderful and can work in IPv6 nicely, but I am not sure it is always "superior" or "preferred".
When saying "Non-MPLS" solution in IPv6, I see the BIERv6-VPN and SRv6-VPN is an opinion (Since we are talking about MPLS, it includes both unicast and multicast).
BIERin6, on the other hand, is "hybrid"---- BIER could be running over IP/IP-GRE/IP-UDP in theory/paper, but for VPN the existing method that preferred is VPN-Label over BIER IMO.

Zzh> BIERin6 is not "hybrid". It has clean layering and can work with SRv6 based VPN. BIERv6 on the other hand it is "hybrid" - it combines BIER/IPv6/VPN into a single layer. One can argue that "integration" is good, but many would say in this case clean layering is much better and more important.

Having said that, I understand that there will be operators insisting on using SRv6 based MVPN/EVPN and BIERin6 still works with it nicely due to its clean layering. The BFIR puts on the SRv6 header, optionally with fragmentation and ESP, and then hand the IPv6 packets to BIER layer, which treats the IPv6 packets as BIER payload. In this model, the destination address is a well-known (either IANA assigned or operator configured) multicast locator plus the func/arg portion that identifies the l2/l3vpn - well aligned with unicast model.

[XJR] Question of MVPN-EVPN support in BIERin6:
I have question on BIERin6 as well about the MVPN/EVPN support for "Non-MPLS" solution in IPv6.
The "existing" solution of MVPN in BIERin6 is RFC8556 (using VPN Label), and you seem to agree that this is something not Non-MPLS, and so you have "VXLAN/NVGRE/GENEVE" for Non-MPLS BIERin6-MVPN/EVPN. Am I understand correct ?

Zzh> No.
Zzh> In current BIER-EVPN draft, vxlan/nvgre/geneve is mentioned only because vxlan/nvgre/geneve can be used for EVPN and BIER-EVPN works with them the same as how BIERin6 work with SRv6 - please see detailed explanation below.
Zzh> First let's forget about SRv6 for one moment - because BIER-EVPN with vxlan/nvgre/geneve does not need to involve SRv6 at all.
Zzh> Ingress PE1 gets a packet from the CE and it puts on a vxlan/nvgre/geneve header with VPN-identifying information embedded. That header is then put into an IPv4/v6 header, and then the entire IPv4/v6 header is treated as BIER payload. This is no different from the MPLS case - the service label comes after the BIER header.
Zzh> Now bring SRv6 in the picture. It is actually no different from vxlan/nvgre/geneve except that the VPN-identifying information is now part of the address. With BIERin6 for SRv6 based MVPN/EVPN/service, the IPv6 packet becomes the BIER payload.
Zzh> In the BIER-EVPN draft, a well-known multicast address is requested from IANA. A single well-know multicast address can be used for both SRv6 and vxlan/nvgre/geneve - that address has Locator:FUNC:arg parts, and FUNC:arg will be 0:0 for vxlan/nvgre/geneve.
Zzh> Jeffrey

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]>
Sent: Thursday, September 10, 2020 8:40 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: draft-xie-bier-ipv6-mvpn question:

[External Email. Be cautious of content]


Hi Jeffrey,
Thanks for your response !
Please see below inline (stripped unneeded text) marked with [xjr2].

Thanks
Jingrong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Thursday, September 10, 2020 8:04 PM
To: Xiejingrong (Jingrong) <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: draft-xie-bier-ipv6-mvpn question:

Jingrong,

Please see zzh> below.


Juniper Business Use Only

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]>
Sent: Thursday, September 10, 2020 3:41 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: draft-xie-bier-ipv6-mvpn question:

[External Email. Be cautious of content]


Hi Jeffrey,
Appreciate sincerely for raising discussions about the draft.
Please see my response inline below marked with [xjr]

Thanks
Jingrong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Thursday, September 10, 2020 4:36 AM
To: Xiejingrong (Jingrong) <[e-mail]>; BIER WG <[e-mail]>
Subject: draft-xie-bier-ipv6-mvpn question:


Zzh> While this draft is about MVPN (though you did talk about VNI below), there is no reason to have a different solution for EVPN, in which case every PE could be a BFIR.
[xjr2] OK. This draft has the same scaling problem surely, and DCB/VNI is particularly needed for such MP2MP model.

Zzh> Whether by signaling or by configuration, the key point is that the egress must carve out the same function portion of the source address for lookup. My understanding is that the locater/function/argument portions are not fixed.
[xjr2] Got it!

Besides, would you think it necessary to extend the "DCB label" to 24bit to cover the VNI length ?
Zzh> This is already covered in RFC8365:
[xjr2] Thanks ! Good to see the example exactly!

Can you elaborate the above scenario (BIERv6 packets unicast to BR and then replicated)? Is it a scenario that must be supported?
[xjr] The above scenario is covered in <draft-geng-bier-ipv6-inter-domain>, so it is not covered in this document, as this document mainly focuses on the "BGP-MVPN" protocol extension.
Zzh> If you're referring to the "peering" model in that draft, which is very controversy, it's better to not mention it here at all. That entire draft should be adequately discussed before other drafts start referring to it.
[xjr2] Got it!

When/where would the above two scenarios (non-segmented and segmented) be covered?
Zzh> I agree the BIFT construction is not the concern of this document - whether segmentation is used or not - and we don't even need to list BIFT construction as "out of scope" (this is referring to the non-segmentation case earlier).
[xjr2] Got it!

[xjr] Haven't considered segmented MVPN in detail yet, Will come back if I have any further thoughts.
Zzh> So the segmentation is not "out of the scope" (otherwise there is no complete solution) - it should be "for further study" or "provided in future revisions".
[xjr2] Good to learn the distinction of these terms in draft writing! Thanks!

Zzh> Thanks.
Zzh> Jeffrey

Thanks.
Jeffrey

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only