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

[duanfanghong <[e-mail]>]

Hi Jeffrey,

For the 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$>, after the presentation in the past IETF 115, you raised some questions and asked me to discuss with you in mailing list.

I think most of the points are discussed in previous mails, some of which we have not reach agreement I list as following:

1．  The scope of this document covers a same point with https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements/.
In my opinion, the initial objective, scenarios and solution of two documents are all different, and there is no regulations that two documents cannot cover a same issue.

2．  C-Multicast routes propagating control solution, RT-constrain only or regular MVPN procedure.
In my opinion, a lightweight modification of regular MVPN procedure as described in my document is better, because it is widely deployed for MVPN and working well. “RT-constrain only” methods faces some precise control problem and deployment problem as I described below.

3．  Root distinguishing for UMH routes.
It is not IPv6 specific, and I have resolve it in the document https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/.

I wonder we can reach some agreement of above points, and help the document evolving further.

Thanks.
Fanghong.

From: duanfanghong
Sent: Thursday, August 4, 2022 12:12 PM
To: 'Jeffrey (Zhaohui) Zhang' <zzhang=[e-mail]>; [e-mail]
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Jeffrey,

Firstly, I think the factor that RT-constrain is widely deployed or not cannot change the fact that it is only an extra procedure for route reflecting / propagating. I insist that to obsolete the endogenous propagating procedure of MVPN and only rely on RT-constrain are not correct, because I have learned from some customers that RT-constrain it not deployed and also not willing to deploy it in future.

Secondly, as I clarified in the past IETF 114, the initial objective, scope and solution of the two documents are different. Even if the propagating issue is addressed in both documents, the solution is difference and there is no regulations that two documents cannot cover a same issue. You are welcome if you’d like to join us to solve the propagating issue in my document 😊.  If you do not want to do so, I think we can keep the two solutions in two separated documents and leave customers to decide which one to use. In addition, we can ask BESS/IDR people and customers to discuss the two solutions.

Please see more dfh8> below.

Thanks.
Fanghong.
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Thursday, August 4, 2022 4:40 AM
To: duanfanghong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

Hi Fanghong,

Let me pull up a key exchange:

Dfh7> So, the solution of C-Multicast propagating relying only on RT-constrain is fully wrong, an endogenous solution in MVPN SAFI is needed to do precise propagating control.

Zzh7> I strongly disagree with the above statement. We can ask BESS/IDR people and customers to speak about whether RT-constrain is a widely deployed essential procedure.
Zzh7> Using the generic RT-constrain mechanism is certainly better than MVPN-specific complicated procedures.

Please see more zzh7> below. I trimmed some email headers.


Juniper Business Use Only
From: duanfanghong <duanfanghong=[e-mail]<mailto:duanfanghong=[e-mail]>>
Sent: Tuesday, July 19, 2022 11:46 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [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,

Thanks for your inviting me to be a co-author of your draft. In your draft, it had several independent point of C-Multicast enhancements, I think it is better to divide them into separated document for each scenario. In my draft, it had a set of issues only focused on MVPN in IPv6 infrastructure scenarios (including root distinguishing issue, propagating control issue, evolution issue). So, I have a suggestion that we work together to resolve those IPv6 underlay related issues in my draft and I’d like to invite you to be a co-author of my draft.

Zzh6> Root distinguishing issue is not IPv6 specific. The C-multicast route propagation issue is one of the issues covered in my draft and it can be solved by the RTC mechanism that removes the complexity of MVPN specific inter-as propagation procedures. Even if we introduce another way to address it, I would say it’s good to include it in a document that covers multiple c-multicast route issues/enhancements.

Dfh7> Although root distinguishing issue is not IPv6 specific, I think it is of no importance in IPv4, because which the ADD-PATH procedure is widely deployed to resolve it in the scenarios of root PEs with same RD even if the solution is not completely reliable in some cases. As I said before, the “Source AS” field  length issue is critical in IPv6, I think an individual document to analysis the gaps and solutions of MVPN in IPv6 underlay network is needed. Even the propagation issue is mentioned in your draft, I still think it is appropriate to include it in my document and perhaps we can work together to improve it. 😊

Zzh7> My point is that root distinguishing issue is not important in your IPv6 specific draft (and I think you agree). Then the main issue of your draft - c-multicast route propagation in case of non-segmented inter-as IPv6 - is already covered in my draft 😊
Dfh8> Root distinguishing is important for IPv6-infras scenarios because of the source AS field length issue, I emphasized this multi times in our discussion.

Following is the question pulled up in your latest mail. For my explanation, please see Dfh6>.

Dfh5> Unfortunately, rt-constrain is not a mandatory SAFI in most real deployment cases, so I still insist that it is not applicable to fully rely on it. Even if rt-constrain is deployed, to find out the specific RT in RT array is needed on ASBRs / RRs. In RFC 6514, the propagating control of C-multicast routes is used not only over the directed EBGP sessions(For the scenarios of ASBRs connected directly) but also over the targeted EBGP sessions.
Zzh5> Can you elaborate the red text above and why does the purple text matter?
Dfh6>

1.       For the red text, I meant that the behavior of RT-constrain procedure performed on leaf PEs / ASBRs is same as the behavior of my modified propagating-along-the-reverse-path-of-I-PMSI procedure performed on ASBRs, of which both need to find out the specific RT in RT array carried in the corresponding C-Multicast routes.

Zzh6> The RTC mechanism is a generic mechanism that works with generic RTs – independent of MVPN. Your proposal checks multiple RTs and uses each IP address specific RT’s IP address to try to find a corresponding Intra-AS I-PSMI, and that’s for non-segmented tunnel only. I would say the generic one is better 😊

Dfh7> I think you misunderstood my solution 😊, my checking procedure only use the C-Multicast RT with non-zero Local Administrator field (which is used to target the C-Multicast route to the corresponding Root PE, and there is only one RT with non-zero Local Administrator field in the RT array of non-segmented Inter-AS C-Multicast route), so it perform a precise propagating control of Inter-AS C-Multicast route.

Zzh7> Ok there is a small misunderstanding but still all the RTs needs to be scanned (to locate the one with a non-zero local admin field).
Dfh8> RT-constrain also scans all the RTs to determine which sessions the routes to be propagated.

Dfh7> In your document, it uses an extra RT-constrain mechanism

Zzh7> RT-constrain mechanism is a widely available and deployed generic feature. You may not agree but I’ll defer to other BESS/IDR folks.
Dfh8> Please see above.

Dfh7> … that cannot perform the same level of propagating control with my modified propagating-along-the-reverse-path-of-I-PMSI procedure, considering a C-Multicast route has two RTs, said RT1 and RT2, which RT1 is the RT used to target the C-Multicast route to the corresponding Root PE (with a non-zero Local Administrator field) and RT2 is an ASBR specified RT or any other type of RT, imaging that there are two BGP sessions to be selected to propagate such C-Multicast route, said session1 and session2, which session1 is allowed to be used to send routes containing RT1 (it is also the BGP session receiving the Intra-AS AD / wildcard S-PMSI AD route sent by the corresponding Root PE) and session2 is allowed to be used to send routes containing RT2 according to the RT-constrain mechanism. Because RT1 and RT2 are both contained in the C-Multicast route, If using RT-constrain as the only mechanism , such C-Multicast route will be propagated through the two BGP sessions, while using my modified propagating-along-the-reverse-path-of-I-PMSI procedure, it will be only propagated to session1 precisely.

Zzh7> First of all, with the RTC mechanism, the there is no need for RT2 that target the c-multicast route to the upstream ASBR anymore.
Dfh8> In segmented inter-AS scenarios, I think the RT of the ASBR of ingress AS is needed, I’ll further discuss this in my document.
Zzh7> Secondly, even if in some theoretical scenarios a route with multiple RTs may go through different sessions, what’s so bad about it? If it is that bad, I suppose there is a larger non-MVPN-specific issue to solve.
Dfh8>  If the problem is not so bad, I think it is no need to do propagating control between ASs.
Dfh8>  Anymore, why we need to obsolete the endogenous and precise propagating control of MVPN ( it is also a widely deployed existing regular procedure of MVPN) to use the unreliable one and reply on an extra SAFI

Dfh7> So, the solution of C-Multicast propagating relying only on RT-constrain is fully wrong, an endogenous solution in MVPN SAFI is needed to do precise propagating control.

Zzh7> I strongly disagree with the above statement. We can ask BESS/IDR people and customers to speak about that.
Dfh8> Please see above also.

Dfh7> For the segmented Inter-AS tunnel, as I said before, its main point is not how to distinguish C-multicast NLRIs but how to make the root protection reliable (Not IPv6 specific, I’ll discuss it in another document I’m working on), it has no issue of C-Multicast propagating control even in IPv6 infrastructure scenarios.

Zzh7> Right; and the main issue in your draft is c-multicast propagation in the case of non-segmented inter-as in IPv6 infrastructure is already solved in my draft; even if we still want to include another solution, it is better to be added to that existing draft.
Dfh8> Please see above also.


2.       For the purple text, I just emphasized  that the propagating-along-the-reverse-path-of-I-PMSI procedure is not only used between two ASBRs connected directly, but also used in the scenarios of reflecting routes from E-BGP sessions to I-BGP on RRs, in the latter case, even if RT-constrain is used, the new code is needed on RRs to obsolete the regular propagating-along-the-reverse-path-of-I-PMSI procedure.

Zzh6> I forgot why new code is needed on RRs for I-BGP case, but even if so, obsoleting complex MVPN-specific procedures is better than introducing addition procedures on top of already-complex procedures.
Dfh7> Obsoleting MVPN-specific procedure is wrong, please see my explanation above. 😊
Zzh7> Also see above 😊
Dfh8> Please see above also.

I just elaborated my modified propagating-along-the-reverse-path-of-I-PMSI procedure is a endogenous solution of C-Multicast propagating control in MVPN SAFI itself and without depending on another BGP SAFI, and it has no other defect while comparing with RT-constrain procedure (in deployment and implementation).

Zzh6> The original procedure and your modification are indeed internal/specific to MVPN, but to me the complexity is not needed when there is a generic well-deployed solution for it 😊
Dfh7> The internal modification of MVPN is needed, only relying on RT-constrain procedure is not sufficient for C-Multicast propagating control (it is only an extra procedure and not widely deployed).
Zzh7> Please see above – we can let BESS/IDR people to speak about if RTC mechanism is widely available and deployed. Even in the intra-AS MVPN case, consider the case where  multicast sources are concentrated to a couple PEs yet all PEs would get the C-multicast routes if RTC was not used …
Dfh8> In Intra-AS MVPN, propagating control of C-Multicast routes is not needed in regular MVPN, RT-constrain can be used as an extra procedure to control the routes propagating if the operator wish to do so, however this is not mandatory.

Zzh7> For MVPN to rely on RTC mechanism for inter-as case, even if code change is needed, it is only to disable the existing complicated procedure.
Dfh8> To obsolete the endogenous propagating procedure of MVPN is not correct. Please see above
Zzh7> Thanks.
Zzh7> Jeffrey

Dfh7> Thanks.
Dfh7> Fanghong.


Dfh5> Distinct RD is an option, if such deployment is not allowed, another solution should be proposed.
Zzh5> What I meant is that, issue #3 (Propagate C-multicast route when non-segmented tunnels are used for IPv6) and distinct RD are agnostic. The solution for #3 should work regardless of whether distinct RD is used or not.
Dfh6> I think there may be several solution to resolve it, we can work together to improve it.
Zzh6> Yes let’s see what we can do here.
Zzh6> Thanks.
Zzh6> Jeffrey

Thanks.
Fanghong.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Tuesday, July 12, 2022 10:13 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,

Please see zzh5> below. I trimmed some mail headings.



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Saturday, June 18, 2022 6:36 AM
To: duanfanghong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.

HI Fanghong,

Let me pull up the points up here at the top.


Dfh3>  I think you were making a mistake, RT-constrain is an extra procedure and cannot run without obsoleting the propagating-along-reverse-path-of-I-PMSI procedure. So, I think the solution you considered is with too many limitation, only applicable in some specific cases with distinct RDs of  <MVPN,PE> tuple and with obsoleting the propagating-along-reverse-path-of-I-PMSI procedure in regular MVPN, and may leave the complication/limitation to deployment.

Regardless of whether RDs are different or not, the solution in draft-zzhang-bess-mvpn-evpn-cmcast-enhancements  (draft-zzhang) works for “non-segmented provider tunnel in IPv6-only network”.
Dfh4>  I don’t think so. If two ingress PEs are with a same RD, Leaf PEs are difficult to perform SFS even if [ADD-PTAH] is enabled on RRs as described in RFC7716, resulting in which two Leaf PEs selecting different ingress PE send C-multicast routes carrying different RT extended community (The global administrator fields are with different originator IP addresses of corresponding ingress PE) but with a same NLRI key because you set the “Source AS” filed to 0 in that document, causing that only one route is selected on RRs / ASBRs and the other one cannot be targeted to the corresponding ingress PE.
Dfh4>  If the RDs are different, your solution is less optimal as you described in that document if RT-constrain is not available.

Zzh4> As you said, “Dfh3> So, This is the reason why I consider two ingress PE with a same RD is a different scenarios”.
Zzh4> This is a summary of all issues that have been talked about:

1.       SFS when same RD (zero or not) are used. This is before C-multicast route is generated

2.       Distinguishing C-multicast routes intended for different ingress PEs when same RD is used (e.g. for live-live protection)

3.       Propagate C-multicast route when non-segmented tunnels are used for IPv6

Zzh4> Your draft has solutions for #2 and #3 but I don’t see you have a solution for #1 (my draft does not address #1 either, though I have some ideas for it).
Dfh5> The issue of  SFS using same RD is not IPv6 specific, and will be addressed in another draft I’m working on.
Zzh5> Good. I also have some thoughts – maybe we can collaborate (more below on that).

Zzh4> Whether it is GTM (RFC7716) or real VPN, when you have same RDs on some/all PEs, #1 and #2 exist regardless of IPv6, intra/inter-as or whether propagating-along-reverse-path-of-I-PMSI is used or not. Even in your draft, solutions for #2 and #3 are different and for different problems.
Zzh4> The root-cause of the #3 “non-segmented tunnel in ipv6” issue that the source AS field is not large enough to carry the IPv6 address of the ingress PE. Using the Ingress PE’s IP address in a RT attached to the route is a solution with its drawbacks (I’ll talk about the drawbacks separately since we now need to clear out some tangled issues). It alone does not address #1 or #2. My “using rt-constrain” solution also only address the same problem of “source as field not large enough to carry IPv6 address”. When I said “Regardless of whether RDs are different or not, the solution in draft-zzhang-bess-mvpn-evpn-cmcast-enhancements  (draft-zzhang) works” is only for issue #3.


Zzh4> Your solution for #2 will not work for segmented tunnel case if I understand it correctly, because the ASBRs needed to use the source as field so you can’t put the generated distinguishing number there.
Dfh5> This document discussed the non-segmented Inter-AS issue, for Inter-AS segmented scenarios, please see below.


RT-constrain is a well-deployed feature. The propagating-along-reverse-path-of-I-PMSI procedures does not need to be “obsoleted” (or a better way to say is that existing code will work with RT-constrain for “non-segmented tunnels in IPv6 provider network”).
Simply put, non-segmented tunnels in IPv6 provider network” works once you use RT-constrain. No new code is needed.
Dfh4>  I don’t think so. The code of C-multicast propagating control in ASBRs must also be modified to do not check the existence of Intra-AS AD if “Source AS” filed is zero according to your solution, otherwise the procedure of your solution cannot run even if RT-constrain is available, because RT-constrain is an extra procedure and before it takes part the routes must complete corresponding processing of MVPN process in which your zero “Source AS” C-multicast routes are processed as invalid routes in regular MVPN because no corresponding Intra-AS AD is found.
Zzh4> I would say that rt-constrain procedures are the more basic/generic BGP infrastructure ones (applicable to all routes with RTs), while the MVPN are the more specific and extra procedures.
Zzh4> To support non-segmented tunnels with the “traditional way”, MVPN procedures specified in RFC6514 need to be implemented and most likely provisioned on ASBRs. To do it with the rt-constrain way, the MVPN procedures does not need to be run – all the ASBRs need to do is to re-advertise the routes (just like how a RR reflect routes, w/ or w/o following rt-constrain) w/o processing them. Even if that means some ASBR needs to have new code to enable the re-advertisement following the rt-constrain procedures, it is better than implementing new procedures looking at the RTs to figure out which I-PMSI route to look up and then decide what new RT to put it. There could be multiple/different RTs in the c-multicast route (e.g. it has at least two RTs – one targeting the ingress PE and one targeting the receiving ASBR) and you need to find the which one to use to locate the Intra-AS I-PMSI route.
Dfh5> Unfortunately, rt-constrain is not a mandatory SAFI in most real deployment cases, so I still insist that it is not applicable to fully rely on it. Even if rt-constrain is deployed, to find out the specific RT in RT array is needed on ASBRs / RRs. In RFC 6514, the propagating control of C-multicast routes is used not only over the directed EBGP sessions(For the scenarios of ASBRs connected directly) but also over the targeted EBGP sessions.

Zzh5> Can you elaborate the red text above and why does the purple text matter?


Dfh3> So, This is the reason why I consider two ingress PE with a same RD is a different scenarios, especially in some real deployment cases, same RD may be needed and important… Our solution is aiming at those cases and helps providing a reliable Single Forward Selection.

Indeed, the RD discussion is for a different issue that is not IPv6 specific. I had acknowledged that very early in this email thread.
However, the following solution in your draft does *not* provide “a reliable Single Forward Selection”:

   3.  If the Originating Router's IP Address field of the found Intra-
       AS I-PMSI A-D route is an IPv6 address and the root PE and leaf
       PE are in the different ASs, a four bytes distinct value MUST be
       assigned by leaf PE for each root PE, the Root Distinguisher
       field in C-Multicast NLRI is filled with this value and a
       distinct C-multicast route will be send to individual upstream
       root PE.

The only way to provide “a reliable Single Forward Selection” is for the UMH routes to carry distinct RDs.
I assume that the above is intended to address the following:


   In [RFC7716<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7716__;!!NEt6yMaO-gk!GaPNeFKLEsSOts5vB_K3a0Kbo-ZZLAFYun3Z5ZjO9AD0WgkvcM4NTnYmedeg37mcGdVj-1IMWpllq4bN37IT77GuKo47Fgpu$>], 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.


Dfh4> In the early part of this discussion, I agreed with you that the RD issue is not specified for IPv6. I think it more critical than IPv4 because the source AS field cannot hold a IPv6 address, this is why I listed it in this document.


Dfh4> I think the main points of what we are discussing are how to send distinct C-multicast routes to different ingress PEs and how to provide “a reliable Single Forward Selection”.



Zzh4> See the three issues I listed above.



Dfh4> 1. To carry distinct RDs which is recommended in RFC 6514 is certainly a way (not the only one) to achieve the two points, however I think it is no need to obsolete the propagating-along-the-reverse-path-of-I-PMSI procedure and only rely on RT-constrain, because the propagating-along-the-reverse-path-of-I-PMSI procedure is a propagating control of MVPN itself and RT-constrain is an extra procedure and not mandatory in deployment. In the propagating control part of my document, it described the solution that using the global administrator fields of RT extended community (it is a new type of RT extended community with both the function of targeting C-multicast routes on ingress PEs and propagating control between ASBRs) instead of the source AS field to control the C-multicast routes propagation between ASBRs, which can apply in both IPv4 and IPv6 infrastructure scenarios. I will add some description in my document for the cases of ingress PE with distinct RD.

Zzh4> For the propagation of c-multicast routes (issue #3), distinct RD is irrelevant, right?

Dfh5> Distinct RD is an option, if such deployment is not allowed, another solution should be proposed.

Zzh5> What I meant is that, issue #3 (Propagate C-multicast route when non-segmented tunnels are used for IPv6) and distinct RD are agnostic. The solution for #3 should work regardless of whether distinct RD is used or not.



Dfh4> 2. In the scenarios of ingress PE with a same RD, the source AS field is used to distinguish C-multicast routes. To provide “a reliable Single Forward Selection”, I explained at the early part that I’ll publish a better solution without relying on [ADD-PATH].

Zzh4> To distinguish C-multicast routes for GTM (not much an issue for regular VPN unless one insists to use the same RD even for live-live protection, which I think is to artificially making it more complicated) – issue #2 – using source AS field would break segmented tunnels, right?

Dfh5> This document discussed the non-segmented Inter-AS issue, for Inter-AS segmented scenarios, please see below.



Zzh4> Looking forward to your solution for #1 (please don’t mention ADD-PATH anymore because it does not address the issue anyway).


Dfh4>  To deploy distinct RDs or not is determined by scenarios, a protocol design of MVPN cannot rely on only one option of them.

However, it has the following issues:


1.       The problem you wanted to address is not specific to IPv6 or Inter-AS or tunnel segmentation, yet the proposal above is IPv6 specific.
       Dfh4> I have explained in the above.


2.       The above solution, even after made IPv6-agnostic, does not work for inter-AS segmentation if we still depend on propagating-along-the-reverse-path-of-I-PMSI.
       Dfh4> In my document, it also considered the compatibility of inter-AS segmentation scenarios, with no modification of the regular MVPN procedure for  inter-AS segmentation propagating.
Zzh4> How do you distinguish two C-multicast NLRIs when the RDs are the same, and source-as field as the same (AS number – vs. a generated distinguishing number)?
Dfh5> In segmented Inter-AS scenarios, If two root PEs are in a same ingress AS, It is hard to perform end-to-end root protection because the Intra-AS AD routes are aggregated to an Inter-AS AD route lacking of the root PEs information. This issue is also not IPv6 specific and its main point is not how to distinguish C-multicast NLRIs but how to make the root protection reliable, I’ll discuss it in another draft.

Zzh5> I happen to also talk about this issue here: https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01*section-1.4__;Iw!!NEt6yMaO-gk!CHgBbJMXEC25e-teoztECNPvL68VSTTruiuZNBqY3wQsGRbGrOSk4MhXECuteHuppO9OiMUHFeJUyUDYkZd2Jk2NaDGZuq-d$> 😊 Even though it is not in the context of root protection, the problem and solution are similar.
Zzh5> It seems that issue #2 and #3 are already covered in the above draft (even though the solutions are different). Even #1 could also be considered related (the SFS leads to C-mcast route). Perhaps we can work together to progress that comprehensive draft? For #3 we can add the option of using RT or a corresponding VRF Import RT EC to look up the Intra-AS I-PMSI.
Zzh5> It currently has four co-authors and we can still add one front-page co-author and some contributors.
Zzh5> Thanks.
Zzh5> Jeffrey

Dfh5> Thanks.
Dfh5> Fanghong

Zzh4> Thanks.
Zzh4> Jeffrey


3.       Just that each egress PE generates distinct values for different ingress PEs is not enough. Say egress PE3 generate 100/200 for ingress PE1/2 respectively, but egress PE4 generates 200/300 for ingress PE1/2 respectively, then PE3’s c-multicast route for PE2 and PE4’s c-multicast route for PE1 would get mixed up.
       Dfh4> What I meant in my document is that each Leaf PE use a same well-known (or configured) hash algorithm to transform the IPv6 root IP to 4-bytes distinct value for each ingress PE, or a provisioning method is used to globally assign different 4-bytes IDs for each ingress PE’s IPv6 address. I’ll detail this in later version.

While the third issue can be easily solved, once the distinct value is generated, it does not need to go into the “source-as” field. It can simply be put into the RD field. The RD field is really just an opaque field when propagating-along-the-reverse-path-of-I-PMSI is not used.

When consider all the factors, here are my observations:


a.       We could really move away from propagating-along-the-reverse-path-of-I-PMSI and just rely on rt-constrain. That will work for “non-segmented tunnels in IPv6” as well.

b.      Regardless whether propagating-along-the-reverse-path-of-I-PMSI is used, it is best to tie the RD to the ingress PEs if you need to target redundant c-multicast routes to different ingress PEs. There are ways to do that even for GTM.

Thanks.
Jeffrey



Juniper Business Use Only
From: duanfanghong <duanfanghong=[e-mail]<mailto:duanfanghong=[e-mail]>>
Sent: Thursday, June 16, 2022 8:50 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [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,

Please see Dfh3> below.

Thanks.
Fanghong

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Thursday, June 16, 2022 10:17 AM
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,

Please see zzh3> below.



Juniper Business Use Only
From: duanfanghong <duanfanghong=[e-mail]<mailto:duanfanghong=[e-mail]>>
Sent: Wednesday, June 15, 2022 3:36 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,

Please see Dfh2> below.

Thanks.
Fanghong

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Wednesday, June 15, 2022 11:41 AM
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,

Please see zzh2> below.



Juniper Business Use Only
From: duanfanghong <duanfanghong=[e-mail]<mailto:duanfanghong=[e-mail]>>
Sent: Sunday, June 5, 2022 10:55 PM
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,

Please see Dfh> below.

Thanks.
Fanghong

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Friday, June 3, 2022 4:06 AM
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,

Please see zzh> below.



Juniper Business Use Only
From: duanfanghong <duanfanghong=[e-mail]<mailto:duanfanghong=[e-mail]>>
Sent: Thursday, June 2, 2022 6:50 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,

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.

Zzh> It mentioned “less optimal” only in the context of not using RT Constrain (RFC 4684). If RFC 4684 procedure is used, then there is no issue at all.
Dfh> Yes, if RT Constrain (RFC 4684) is used, both solutions can reach the same level of propagation control.
Zzh> The procedure of propagating C-multicast routes in the reverse path of I-PMSI routes is complicated. We can get away with not using it at all.
Dfh> In some real deployment, operators may not select RT Constrain as a mandatory option. In that case, a precise control is needed.


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.



Zzh> Is it that 0:0 RD issue is independent of IPv6 and “source-as” field length issue, and the latter already has a (better, simpler and more general) solution?

Dfh> The issue for 0:0 RD or two ingress PE with a same RD is not a specific problem for IPv6 infrastructure, it seems more crucial than IPv4 together with the issue  of “source-as” field length. I’m writing a better solution (without enabling ADD-PATH on RRs or carrying different RDs in UMH routes) to update another draft “https://www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-00.txt<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-00.txt__;!!NEt6yMaO-gk!E0cAwbF2FJZ4JBNFtUmdWW8losqIPKA6JoEjREF7yrPtn6CnEcKs788GchHxAQy4znjVDKqH3VvwxKqP5WBFjAsTT6ZM7LJg$>”, which a new version will be published before IETF 114.

zzh> BTW, I think you missed mentioning that now the C-multicast routes need carry an “IPv6 VRF Route Import Extended Community” that is copied from the UMH route, in addition to RTs (one of which matches but is not the same as the “IPv6 VRF Route Import Extended Community”).

Dfh> I think only one “IPv6 VRF Route Import Extended Community” is needed. In our solution, Leaf PEs sent distinct C-multicast routes for each ingress PE, each C-multicast route carried a “IPv6 VRF Route Import Extended Community” copied from the UMH route sent by the corresponding ingress PE. This procedure is using what described in RFC 6515 & RFC 6514, so we did not emphasize it.

Zzh2> C-multicast routes don’t just copy “VRF Route Import Extended Community” from the UH route. It uses that to construct a RT Extended Community – the two are different.

Dfh2> What I was saying is that the main part of the RT Extended Community is constructed from VRF Route Import Extended Community.

Zzh2> More importantly, there is just no advantage of using the flawed/complicated procedure (of following reverse path of I-PMSI or (*,*) S-PMSI route), when the RT-constrain based propagation works well (and that should be widely deployed).

Dfh2> In your sentence of ‘that should be widely deployed’, I think you were making a mistake to use the key word ‘SHOULD’ which should be instead of the key word ‘MUST’. In your considerations, ingress PEs also ‘MUST’ be configured with a distinct RDs and the propagation procedures of C-multicast routes in RFC 6514 also ‘MUST’ be obsoleted, otherwise the RT-constrained procedure also cannot work.



Zzh3> By “that should be widely deployed” I meant to state an opinion that RT-constrain based VPN-IP (not C-multicast) route propagation is now already widely deployed (so using it for C-multicast route propagation is natural and simple).

Zzh3> RFC6514 itself actually does depend on that all PEs use different RDs (even for the same VPN). That is what I learned from Eric Rosen some time after getting into BGP-MVPN. Configuration different RDs is also a common practice even for unicast.

Zzh3> If they don’t use different RDs, then Single Forward Selection won’t work reliably (even for true VPN vs. GTM) as explained in the GTM RFC. Even for the other way of determining upstream PE (based on unicast route), you may not get desired result because an egress PE may not get the UMH route advertised by the ingress PE closest to it (a RR in the path may re-reflect a route from an ingress PE further away from this egress PE).

Dfh3> So, This is the reason why I consider two ingress PE with a same RD is a different scenarios, especially in some real deployment cases, same RD may be needed and important… Our solution is aiming at those cases and helps providing a reliable Single Forward Selection.



Zzh3> With RT-constrain procedure, because the C-multicast route contains a RT for the ingress PE, no matter what the ASBRs do, the route will be propagated to the ingress PE because of the RT-constrain procedure. Even if “obsoleting” is needed (to go with the rt-constrain approach), it is easier/better to obsolete the propagating-along-reverse-path-of-I-PMSI procedure that is flawed and complicated instead of patching it up.

Dfh3>  I think you were making a mistake, RT-constrain is an extra procedure and cannot run without obsoleting the propagating-along-reverse-path-of-I-PMSI procedure. So, I think the solution you considered is with too many limitation, only applicable in some specific cases with distinct RDs of  <MVPN,PE> tuple and with obsoleting the propagating-along-reverse-path-of-I-PMSI procedure in regular MVPN, and may leave the complication/limitation to deployment.





Dfh2> It seems that our discussion returns to the first step, which you insisted that the RDs of ingress PEs are always different while I considered the scenarios of real deployments with a same RD and proposed a more flexible solution for these cases. So, I think we can reach a conclusion that scenarios of what we discussed are different.



Zzh3> Please see above, and https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01*section-1.2.2__;Iw!!NEt6yMaO-gk!DnFIzEL2EAnQWk8qFCKO124ZBhg79kDevkNtZBMumkf5b2Q8Kw9jeuX6Ihfs7r50luNdOsg31qgxIrsADKu3Krhz_gyARWcj$>, https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01*section-1.2.1__;Iw!!NEt6yMaO-gk!DnFIzEL2EAnQWk8qFCKO124ZBhg79kDevkNtZBMumkf5b2Q8Kw9jeuX6Ihfs7r50luNdOsg31qgxIrsADKu3Krhz_ltaW5L8$>.



Dfh2> Anymore, I think that to limit the configuration or deployment is not always a good principle for protocol design, which may leave the complication to operators.



Zzh3> I would consider the existing propagating-along-reverse-path-of-I-PMSI procedure is not a good protocol design (at least for the non-segmented tunnel case) because it is complicated and not needed.

Dfh3>  I cannot agree with you. Propagating-along-reverse-path-of-I-PMSI procedure is a propagating control of MVPN itself and do not rely on any other protocol / SAFI.

Dfh3>  Fanghong.



Zzh3> Jeffrey


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.

Zzh> Is this an information/BCP kind of document?
Dfh> In this document, it redefined the ‘source-as’ field to ‘root-distinguisher’ filed, introduced a new procedure to deal with the new field, and addressed the IPv4 to IPv6 migration problems, so it is a protocol specification and with a intended status of ‘Standards Track’.
Zzh2> I was referring to the optimization of route propagation on the dual sessions, not referring to redefining root-distinguisher field.
Dfh2> Both of the procedure are with a intended status of ‘Standards Track’.

Zzh> BTW, is it ok to for a RR to just reflect routes received on v4 sessions to other v4 sessions, and reflect routes received on v6 sessions to other v6 sessions?
Dfh> In the IPv4 to IPv6 migration scenario, IPv4 BGP sessions and IPv6 BGP sessions are parallel everywhere and a BGP speaker can detect whether the two type of BGP sessions are parallel or not, so when a PE originated / received a MVPN route and decide to send it to neighbors, it is reasonable to determine which address type of BGP sessions to be sent to by using the infrastructure address type of the sending MVPN route, this solution can help control / reduce the explosion of MVPN route’s PATHs.
Zzh2> I was asking that if a RR “just reflect routes received on v4 sessions to other v4 sessions, and reflect routes received on v6 sessions to other v6 sessions”, would that solve the problem? Is it that during incremental update there could be single-session situations?
Dfh2> Yes, I think it will works well. Without the proposed procedure, the number of PATHs of MVPN routes will be doubled by each RR because of the parallel BGP sessions between the RR and other devices.
Dfh2> As I explained before, the single-session situations can be detected and without using the proposed procedure.
Dfh2> Thanks.
Dfh2> Fanghong.

Zzh2> Thanks.
Zzh2> Jeffrey


Zzh> Jeffrey

Thanks.
Fanghong.
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Tuesday, May 31, 2022 11:57 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,

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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7716__;!!NEt6yMaO-gk!CRxUJ5O7pnF1DFfZilrqRplvWUQ4cTP-OWfCGpmEJ_Ra41xbWykb_9Wk5Ccw98vCC_KCVJqqZea37vSGBHoG1qLOkPgHB1MG$>], 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 – 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