Hi Vinod Kumar, Thanks for your questions. Please see WH below.
From: Vinod Kumar Nagaraj [mailto:[email protected]]
Sent: Monday, July 25, 2022 6:10 PM
To: [email protected]; Wangheng (MCAST, P&S) <[email protected]>; duanfanghong
<[email protected]>
Subject: [bess] draft-wang-bess-mvpn-upstream-df-selection-01.txt
Hi Heng/Fanghong,
I had few queries as below w.r.t draft-wang-bess-mvpn-upstream-df-selection-01,
1. Abstract
The downstream PEs, accordingly, send C-multicast routes to both the primary
and standby upstream PEs and forward the multicast flow comming from both sides
to the CEs.
Please edit the last part of sentence as 'forward the multicast flow coming
from either side to the CEs.'
WH: Ok, we will rephrase the description.
2. Introduction says that there are problems with hot root standby procedures
in RFC 9026 - Duplicate traffic in Core and monitoring P-tunnel status via BFD.
Then it goes on to say that the current draft proposes a different 'warm
root standby' mechanism.
So this draft does not address problems with hot root standby' procedures ?
Only proposing alternate way of doing 'warm root standby' ?
WH: Yes, we consider that the problems in the 'hot' method do not exist in the
'warm' one, however, the 'warm' convergence performance is not as good as 'hot'.
So our main purpose is to improve the 'warm' procedure to gain a better
convergence performance.
3. multi homing ingress PEs to determine "locally" a single forwarder to avoid
duplicate packets sending through the backbone, without the egress PEs' primary
or
standby UMH selection.
The above snippet from Introduction is not completely correct. Egress PE is
sending C-multicast join to both Primary and Backup Upstream PEs, which means
UMH selection is happening on Egress PEs. Please re-phrase.
WH: Yes, egress PEs do perform UMH selection and send C-multicast join to both
sides, but an egress PE do not need to decide which one is primary or standby,
it just consider all the ingress PEs equal.
We will rephrase the description to clarify the procedure.
4. Draft proposes
A) upstream DF election between multi-homing ingress PEs.
B) Downstream PEs advertising Primary and Standby C-multicast routes and
accepting traffic from either of the upstream PEs.
How does an implementation detect an Upstream MVPN PE ? It's only on
receiving a BGP C-multicast route from remote/downstream PE, that an
implementation can detect the PE as Upstream.
There is time involved in detecting upstream PE, detecting multi-homed
upstream PEs and kickstarting upstream DF election. Multicast convergence would
take a hit.
WH: The Upstream PEs detection for a given (C-S, C-G) flow could be implemented
by some administrative measure such as configuration or deployment,
which do not depend on receiving C-multicast routes from other PEs.
5. Warm standby solution in RFC 9026 does not forward Duplicate traffic into
Core. Traffic from CE would hit Standby Upstream PE, but the Standby PE
wouldn't put the traffic into the core/PMSI.
I am not able to see the gain these alternate procedures bring when
compared to warm standby procedures in RFC 9026.
RFC 9026 Hot root standby procedures forward redundant copies into the core to
ensure fast failover ( sub second multicast convergence in the event of any
failures in upstream path ). For optimal multicast convergence , hot root
standby procedures need to be turned on.
Do the procedures proposed in this draft guarantee optimal multicast
convergence like hot root standby procedures ?
WH: The main warm standby procedure difference between RFC9026 and this draft
is that the 'selection action' is performed by Downstream PEs or by Upstream
PEs.
If the selection is performed by a downstream PE, Indeed the convergence
performance is not as good as hot root standby.
But if the selection is performed by a upstream PEs, it could be more likely to
reach a same level.
Regards,
Vinod Kumar.
Juniper Business Use Only
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
