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”.
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.
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://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.
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.
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.
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.
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 <[email protected]>
Sent: Thursday, June 16, 2022 8:50 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]
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:[email protected]]
Sent: Thursday, June 16, 2022 10:17 AM
To: duanfanghong <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.
Hi Fanghong,
Please see zzh3> below.
Juniper Business Use Only
From: duanfanghong
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, June 15, 2022 3:36 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Wednesday, June 15, 2022 11:41 AM
To: duanfanghong <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.
Hi Fanghong,
Please see zzh2> below.
Juniper Business Use Only
From: duanfanghong
<[email protected]<mailto:[email protected]>>
Sent: Sunday, June 5, 2022 10:55 PM
To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Friday, June 3, 2022 4:06 AM
To: duanfanghong <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
Subject: RE: [bess] A new draft for MVPN in IPv6-only network.
Hi Fanghong,
Please see zzh> below.
Juniper Business Use Only
From: duanfanghong
<[email protected]<mailto:[email protected]>>
Sent: Thursday, June 2, 2022 6:50 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Tuesday, May 31, 2022 11:57 PM
To: duanfanghong <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>>
Sent: Monday, May 30, 2022 2:32 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Thursday, May 26, 2022 10:23 PM
To: duanfanghong <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>> On Behalf Of
duanfanghong
Sent: Tuesday, May 24, 2022 8:24 AM
To: [email protected]<mailto:[email protected]>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>; Gengxuesong (Geng
Xuesong) <[email protected]<mailto:[email protected]>>; Wangheng
(MCAST, P&S) <[email protected]<mailto:[email protected]>>
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
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
