Hi Siyu,
Please see comments below.
For the "hot root standby"
mechanism, all the ingress PEs, regardless of the primary or standby
role, forward (C-S,C-G) flow to other PEs through a P-tunnel, forcing
the egress PEs to discard all but one, which will cause the steady
traffic redundancy throughout the backbone network. In the scenarios
of enterprise networks crossing provider networks, the waste of
bandwidth is a crucial issue causing the increasement of the OpEx of
enterprise networks, and the "warm root standby" mechanism is
expected to be a better solution.
The mentioning of Hot Root Standby (HRS) should be removed.
It is specifically designed for scenarios where it is critical for
egress PEs to receive but discard duplicates and BW consumption
is not a concern. Where BW is a concern, the Warm Root Standby
(WRS) can be used.
This draft should only compare to WRS.
However, there are some problems
when deploying the "warm root standby" mechanism described in
[RFC9026].
a. Upon the failure of primary ingress PE, the standby ingress PE
needs to send PIM join hop by hop toward multicast source for
each multicast flow and the time when the standby ingress PE
switches to the primary role may be inconsistent with the time
when the leaf PE determines to accept multicast traffic sent by
the standby root, causing which the failover time can hardly
reach the same level of "hot root standby" mechanism.
This point should be removed because it describes Cold Root Standby.
With WRS in RFC9026, traffic already arrives on both PEs.
b. There is no endogenous mechanism for standby ingress PEs to
discover and detect the failure of primary ingress PEs, resulting
in the uncertainty in deployment and implementation.
What's the problem of relying on egress PEs detecting the failure of primary PE?
c. In [RFC9026], the standby ingress PE is determined by using
"Standby PE Community" carried in the C-Multicast routes. The
premise of this mechanism is that all leaf PEs choose the same
primary and standby ingress PEs, which may not be meeted due to
transient unicast routing inconsistencies, the inconsistencies of
P-Tunnel status determined by each leaf PE or lack of support of
the Standby PE community on leaf PE, causing that the "warm root
standby" mechanism is not stable and returns to "hot root
standby" mode because the standby ingress PE also sends multicast
traffic to backbone when the condition is not satisfied.
The potential inconsistent choice among egress PEs is likely because that
the tunnel branches may be up to some egress PEs while down to others.
That is actually a good reason for different choices - we don't want some egress
PEs to not be able to receive from the primary PE. Besides, MVPN handles that
situation well (remember that each egress PE can choose its ingress PE -
see the "Another procedure ..." paragraph in
https://www.rfc-editor.org/rfc/rfc6513.html#section-5.1.3).
If it desired to avoid that, the tunnel status consideration can be skipped
and you'll get consistency that your draft wants, but both are at the cost of
some egress PE may not be able to receive traffic.
d. The primary and standby role is fixed for each multicast flow,
resulting in that ingress PEs cannot perform load balancing for
multicast traffic. Only two ingress PEs are selected for all
multicast stream from a specific multicast source, causing that
the "warm root standby" mechanism cannot be used in the scenarios
of client nework multihoming to more than two ingress PEs.
I don't think that is true. The same Single Forward Selection rules in RFC6513,
which can do load balancing (see 5.1.3 of RFC6513) among different
(C-S,C-G) flows, can be used to
choose both primary and secondary UMH (the secondary one can be
chosen the same way after excluding the primary one). If RFC9026
is not clear about that, it can be clarified.
anycast RPF checking mechanism in dataplane
The word "anycast" is misleading. You should say that traffic from any of the
ingress PEs can be accepted.
... According to the negotiation community, a distinct
C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into
the anycast RPF tunnel checklist of the corresponding multicast
traffic (C-S, C-G).
This means, if there are four ingress PEs for the same flow,
all of them will receive the C-multicast route. With the RFC9026 procedure,
only two of them will, and the selection can still be based on (s,g).
In summary, I don't see sufficient advantages of developing another solution
now that RFC9026 have been implemented and deployed.
For the scenarios of the same RD, this document introduces a new type
of UMH route to be sent in MVPN SAFI, of which the NLRI key consists
of the following fields:
Instead of advertising the UMH route with the MVPN SAFI, we might as well
advertise with the VPN-IP SAFI with RD/RT, and use RT to import into the
default instance. It does not need any signaling changes and depending on
implementation it may just work. We wrote a draft and circulated internally/
externally back in July 2022, but I am surprised that it was not posted.
I will forward you a copy for your review.
With this, it not only solves MVPN problem, but can also be used for unicast.
Thanks.
Jeffrey
Juniper Business Use Only
-----Original Message-----
From: BESS <bess-boun...@ietf.org> On Behalf Of Chensiyu (Susie)
Sent: Monday, November 21, 2022 7:27 AM
To: bess@ietf.org
Cc: duanfanghong <duanfangh...@huawei.com>
Subject: [bess] FW: New Version Notification for
draft-wang-bess-mvpn-upstream-df-selection-03.txt
[External Email. Be cautious of content]
Hi all,
A new version of the draft
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyAEwJo9O$
is published, in which the root PEs differentiation issue of UMH route and
dual-root protection issue in Segmented Inter-AS Scenario are resolved.
We are looking forward to more comments, it would be appreciated if you can
give some valuable suggestions to help us evolve it further .
Regards,
Siyu Chen
-------------------------------------------------------------------------------------------------------
A new version of I-D, draft-wang-bess-mvpn-upstream-df-selection-03.txt
has been successfully submitted by Siyu Chen and posted to the IETF repository.
Name: draft-wang-bess-mvpn-upstream-df-selection
Revision: 03
Title: Multicast VPN Upstream Designated Forwarder Selection
Document date: 2022-11-21
Group: Individual Submission
Pages: 16
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-03.txt__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyIh-akra$
Status:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyAEwJo9O$
Htmlized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-wang-bess-mvpn-upstream-df-selection__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyGr5TPdY$
Diff:
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-wang-bess-mvpn-upstream-df-selection-03__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyDj7YPMP$
Abstract:
This document defines Multicast Virtual Private Network (VPN)
extensions and procedures of designated forwarder election performed
between ingress PEs, which is different from the one described in
[RFC9026] in which the upstream designated fowarder determined by
using the "Standby PE Community" carried in the C-Multicast routes.
Based on the DF election, the failure detcetion point discovery
mechanism between DF and standby DF is extended in MVPN procedures to
achieve fast failover by using BFD session to track the status of
detection point. To realize a stable "warm root standby", this
document obsolete the P-Tunnel status determining procedure for
downstream PEs in regular MVPN by introducing an anycast RPF checking
mechanism in dataplane as an instead.
The IETF Secretariat
_______________________________________________
BESS mailing list
BESS@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyIKMC0SE$
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
