Re: [bess] A new draft for MVPN in IPv6-only network.

[duanfanghong <[e-mail]>]

Hi Jeffrey,

In the draft I published, we focus on the problems and solutions of MVPN in IPv6-only infrastructure and dual-stack infrastructure. Although the "source-as" field length problem overlaps with the one mentioned in your draft, I think it does not prevent moving our draft forward.

1£®  In our draft, we introduce a solution to do precise control of C-multicast routes propagation between ASBRs, not a less optimal one (In your draft, it is mentioned that the solution for this problem is less optimal) than regular solution in RFC6514.

2£®  To configure distinct RDs for each ingress PEs, it is not applicable for some real deployment scenario because of some provision reason. It does exist this problem even in IPv4 infrastructure and become more critical in IPv6 infrastructure because of above "source-as" field length problem.

Our solution does not try to solve all the problems of ADD-PATH, but it is effective for most scenarios when the ingress PEs carries the same RD.
3.    In addition, we also mentioned the IPv4 to IPv6 migration problems, and listed some suggestions to control the explosion of MVPN route¡¯s PATHs.

Thanks.
Fanghong.
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Tuesday, May 31, 2022 11:57 PM
To: duanfanghong <[e-mail]>; [e-mail]
Cc: Xiejingrong (Jingrong) <[e-mail]>; Gengxuesong (Geng Xuesong) <[e-mail]>; Wangheng (MCAST, P&S) <[e-mail]>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

My understanding of the main problem that is pointed out in your draft is that the ¡°source-as¡± field cannot hold an IPv6 address that is required for non-segmented tunnels in case of IPv6 infrastructure.
The draft I referred to also pointed out that problem, and gave a solution (that also has other benefits) that obsoletes the requirement of encoding that IPv6 address.

That¡¯s why I think the (main) problem in your draft is already (better) addressed.

Upon further reading of your draft, I realized you also talked about another problem:


   In [RFC7716<https://datatracker.ietf.org/doc/html/rfc7716>], zero RD is introduced in BGP MVPN NLRIs to enable

   Global Table Multicast service in provider's networks.  In IPv6

   infrastructure networks, Leaf PEs cannot send two distinct

   C-multicast route to two individual upstream root PEs for selctive

   forwarding, because the RD of the two roots is the same.

That does not seem to be specific to IP6 though ¨C we have the same problem with IPv4, and that¡¯s why RFC 7716 has ¡°2.3.4.  Why SFS Does Not Apply to GTM¡±.
The simple solution to that problem is not using SFS, and if it is desired to target c-multicast routes to different upstream PEs (e.g. for live-live redundance), we could enhance the 7716 procedures to allow non-zero RDs even for GTM. That does not need to change the c-mcast format (as RD is supposed to be treated as opaque info).

You mentioned problem with ADD-PATH. Not sure if why ADD-PATH came into the picture at all. RFC 7716 mentioned ADD-PATH but it is meant to say that even ADD-PATH would not solve the SFS problem.

Thanks.
Jeffrey



Juniper Business Use Only
From: duanfanghong <duanfanghong=[e-mail]<mailto:duanfanghong=[e-mail]>>
Sent: Monday, May 30, 2022 2:32 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>; Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>; Wangheng (MCAST, P&S) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi Jeffrey,

I have read your draft carefully, as you mentioned in this draft, it is a less optimal solution for PE to PE C-Multicast signaling.

In the draft I just published, we describe IPv6-only infrastructure and dual-stack infrastructure issues and solutions for regular option B scenario in RFC 6514. So, both the scenario and solution are different from the one you published.

Thanks.
Fanghong.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Thursday, May 26, 2022 10:23 PM
To: duanfanghong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>; Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>; Wangheng (MCAST, P&S) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

It seems that https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01*section-1.3__;Iw!!NEt6yMaO-gk!An361zOjmlWoNMSf73DSUaS8_rgACyWhpJqXDXIsOskU1Mu_2aAJvWLQcqzYMgIYjZ0i9ZWt3JEeKLEWNckNoq6_VOuxU5Iz$> talked about the problems and a more general solution.

That draft also has other enhancements considerations. It has stalled but looks like we should get it going.

Thanks.
Jeffrey



Juniper Business Use Only
From: BESS <[e-mail]<mailto:[e-mail]>> On Behalf Of duanfanghong
Sent: Tuesday, May 24, 2022 8:24 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>; Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>; Wangheng (MCAST, P&S) <[e-mail]<mailto:[e-mail]>>
Subject: [bess] A new draft for MVPN in IPv6-only network.

[External Email. Be cautious of content]

Hi All,

  MVPN(RFC 6513/RFC 6514/RFC 6515) faces some problems in IPv6-only networks, especially in the non-segmented inter-AS scenario and IPv4 to IPv6 migration scenario.
  We have published a new draft https://datatracker.ietf.org/doc/draft-duan-bess-mvpn-ipv6-infras/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-duan-bess-mvpn-ipv6-infras/__;!!NEt6yMaO-gk!An361zOjmlWoNMSf73DSUaS8_rgACyWhpJqXDXIsOskU1Mu_2aAJvWLQcqzYMgIYjZ0i9ZWt3JEeKLEWNckNoq6_VHqmJjHC$>, aiming to solve these problems.

  Please provide your valuable comments and help evolving it further.

  Thanks.

Regards,
Fanghong