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.’
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’ ?
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.
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.
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 ?
Regards,
Vinod Kumar.
Juniper Business Use Only
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
