Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[duanfanghong <[e-mail]>]

Hi Jeffrey,

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs.

So I understand the “multicast locator” you are saying is using the multicast address (rfc4291 section-2.7).
SPRING working group have just discussed about this:
https://mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/
“If so, it really does not conform to SRv6 data plane.”

I think this is a big change and should be discussed in SPRING working group.

Zzh3> I don’t see that it needs to stacked and there is no plan to do so.

Do you also use the “multicast locator” here ?

Anyway, it is a bigger change than above, with consenquences we can’t easily imagine.

I don’t think it is reasonable, far more an implementation concern I have already raised about forwarding plane or control plane.

Thank you.


From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Thursday, March 4, 2021 3:54 AM
To: duanfanghong <[e-mail]>; [e-mail]; BIER WG <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh3> below.

From: duanfanghong <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 3, 2021 8:45 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey

Overhead of encapsulation is a concern but we can talk about it later. Please see my comments  with ‘Dfh>’ below.

From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Wednesday, March 3, 2021 9:20 AM
To: duanfanghong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh2> below.

From: duanfanghong <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 2, 2021 6:46 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey and Sandy,

o In option 1, do you mean that, an entire IPv6 header is added between BIER header and the customer multicast packet with a BIER Proto value 6 used?

  Consider non-BFR case like this:
  A(bfr) ---- B(nonbfr) ---- C(nonbfr) ---- D(nonbfr) ---- E(bfr)
  You need an IPv6 Header + BIER Header + IPv6 Header + customer multicast packet encapsulation ?

Zzh2> This was discussed in the last round.
Zzh2> If both IPv6 based fragmentation and tunneling are needed, then indeed two IPv6 headers are used in the cleanly layered architecture.
Zzh2> I pointed out that when IPv6 is used for everything everywhere, then you don’t get to complain about the additional overhead. For comparison, with BIERv6, you’re using the IPv6 header even between directly connected neighbors where a simple l2 header is enough; with BIERv6, if FRR is used in the network, my understanding is you’ll also have two IPv6 headers – one pushed by the BFIR and the other pushed by the PLR.
Zzh2> If one really cares about reducing the overhead, then doing fragmentation/ESP without requiring IPv6 but in a layer independent way is a better solution and that still achieves clean layering.

  Here are some further questions about the inner IPv6 header : 1) what does "multicast locator"  mean? 2) what is the source address of the inner IPv6 address?

Zzh2> A multicast locator is similar to unicast locator but the difference is that multiple nodes can receive traffic addressed to that <locator + func/arg>.
Dfh> Still don’t understand “similar to unicast locator”, and “multiple nodes can receive traffic addressed to that <locator + func/arg>”.
Is it something like “Replication SID” in <draft-ietf-pim-sr-p2mp-policy>?
Or can you please give an example of a multicast locator showing the locator and func/arg part?

Zz3> It’s different from the “replication sid”. Per RFC 8986:

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128, then
   the remaining bits of the SID MUST be zero.

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs. Obviously, we don’t need to setup multicast trees for those addresses on the transit nodes (because BIER is doing the distribution), but the BFERs have corresponding FIB entries with END.DT4/6/2M forwarding behaviors.

Zzh2> The inner address is the BFIR’s address, since it is the node that imposes that inner IPv6 header.

o In option 2, do you mean that, an IPv6 address is added between the BIER header and the customer multicast packet with a BIER Proto value TBD used?

Zzh2> Yes.

  So an IPv6 address is floating in a place outside of any IPv6 header? I don't think it's reasonable.

Zzh2> Why not? We only need the IPv6 address for service delimiting and don’t need anything else provided by a full IPv6 header. In fact, only the func/arg part is needed so a 32-bit value is practically enough; though for theoretical flexibility provided by variable length of func/arg bits, the entire IPv6 address is used.
Dfh> So I understand the “IPv6 address” is used outside of any IPv6 header, making “IPv6 address” like an MPLS Label.
Could more IPv6 addresses be directed stacked just like MPLS Label stack ?
Zzh3> I don’t see that it needs to stacked and there is no plan to do so. For example, for EVPN BUM with MPLS forwarding plane, a label stack (of two) are used to identify the bridge domain and source Ethernet Segment together, but with SRv6, they are identified with FUNC+ARG in a single SID.
Zzh3> Thanks.
Zzh3> Jeffrey

Zzh2> Jeffrey

Thank you


From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Tuesday, March 2, 2021 10:32 AM
To: duanfanghong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh> below.

From: BIER <[e-mail]<mailto:[e-mail]>> On Behalf Of duanfanghong
Sent: Monday, March 1, 2021 8:23 PM
To: [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi,

I see this document proposes 2 options for MVPN/EVPN.
One is using the destination address to carry the ID of an MVPN/EVPN, but this means that every BFR have to be aware of the MVPN/EVPN instance, introducing state of MVPN/EVPN service and forwarding overhead in transit BFR nodes.

Zzh> This is not true. In this option, IPv6 is payload and is only exposed at the BFER. We have talked this in the last round of discussion.

The other is to use an IPv6 address after a BIER header and before the customer IP packet, however it proposes a new Proto value and new process in forwarding plane.

Zzh> BIERv6, with its companion MVPN/EVPN solution, also requires new process in forwarding plane.

I think both of the options have obvious defects,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

and thus I do not support the adoption.

Thanks !
Fanghong Duan


From: BIER [mailto:[e-mail]] On Behalf Of Greg Shepherd
Sent: Friday, February 26, 2021 12:37 AM
To: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Thank you all for the active discussion that brought us to consensus. This draft now addresses all of the points of discussion for the solution.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!Wz3exwJN85TEXwRgTI9gEwvjszwONVImICqBRh9GKk0mHtpLuzDK9Nf4DnO7hYbt$>

Please reply to this thread with your support/opposition of WG adoption of the draft.

Thanks,
Shep
(Chairs)


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only