[RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10

Zheng Zhang via Datatracker <noreply@ietf.org> Thu, 24 October 2024 04:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from [10.244.8.251] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id A72E3C14F6A6; Wed, 23 Oct 2024 21:38:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Zheng Zhang via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172974468332.2446052.2967041007611648741@dt-datatracker-78dc5ccf94-w8wgc>
Date: Wed, 23 Oct 2024 21:38:03 -0700
Message-ID-Hash: E7MKCQS6BIWLNAA4JWAEYMMGGEBQ24OH
X-Message-ID-Hash: E7MKCQS6BIWLNAA4JWAEYMMGGEBQ24OH
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: bess@ietf.org, draft-ietf-bess-evpn-redundant-mcast-source.all@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Zheng Zhang <zhang.zheng@zte.com.cn>
Subject: [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/UK8Sxh9SbjyOAbyGt5Q8WbLy8YI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Reviewer: Zheng Zhang
Review result: Ready

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

Document: draft-ietf-bess-evpn-redundant-mcast-source-10.txt
Reviewer: Zheng Zhang
Review Date: Oct 24th, 2024
Intended Status: Standards Track

Summary:
No issues found. This documents is ready to proceed to next step.

Comments:
Generally, the draft written clearly.
Please consider the comments listed to improve the draft.
Overall, please replace the [I-D.ietf-bess-evpn-irb-mcast] with [RFC9625].
Please find the comments below with ZZ>.

              Multicast Source Redundancy in EVPN Networks
             draft-ietf-bess-evpn-redundant-mcast-source-10
Abstract
......
1.  Introduction
......
   The solution provides support for Warm Standby and Hot Standby
   redundancy.  Warm Standby is defined as the redundancy scenario in
   which the upstream PEs, attached to the redundant sources of the same
   tenant, make sure that only one source of the same flow can send
   multicast to the interested downstream PEs at the same time.  In Hot
   Standby mode, the upstream PEs forward the redundant multicast flows
   to the downstream PEs, and the downstream PEs make sure only one flow
   is forwarded to the interested attached receivers.
ZZ> It's better to move the Warm Standby and Hot Standby explaination to
Terminology section.

......
4.  Warm Standby (WS) Solution for Redundant G-Sources

   The general procedure is described as follows:
ZZ> It's better to add a 'specification' sub-section for the solution procedure
description.

   1.  Configuration of the upstream PEs
......
   2.  Signaling the location of a G-source for a given Single Flow
       Group
......
       *  The S-PMSI A-D route is imported by all the PEs attached to
          the tenant domain.  In order to do that, the route will use
          the SBD-RT (Supplementary Broadcast Domain Route Target) in
          addition to the BD-RT (Broadcast Domain Route Target) of the
          Broadcast Domain over which the G-traffic is received.  The
          route SHOULD also carry a Designated Forwarder Election
          Extended Community and a flag indicating that it conveys an
          SFG.  The Designated Forwarder Election extended community and
          its use is specified in [RFC8584].
ZZ> Since the SBD-RT may not existed if there is no multiple BDs, please add
"if the SBD exists" to the SBD-RT description.

......
4.1.  Warm Standby Example in an OISM Network
......
   The Warm Standby solution works as follows:
......
   2.  Signaling the location of S1 and S2 for (*,G1)
       Upon receiving (S1,G1) traffic on a local Attachment Circuit, PE1
       and PE2 originate S-PMSI A-D (*,G1) routes with the SBD-RT
       (Supplementary Broadcast Domain Route Target), Designated
       Forwarder Election Extended Community and a flag indicating that
       it conveys a Single Flow Group.
ZZ> The "a flag" indicates the "Single Flow Group (SFG) flag" defined in
Multicast Flags Extended Community Flag, right? Please replace the 'a flag'
with the "SFG flag".

......
   The end result is that, upon receiving reports for (*,G1) or (S,G1),
   the downstream PEs (PE3 and PE5) will issue SMET routes and will pull
   the multicast Single Flow Group from PE1, and PE1 only.  Upon a
   failure on S1, the Attachment Circuit connected to source S1 or PE1
   itself will trigger the S-PMSI A-D (*,G1) withdrawal from PE1 and PE2
   will be promoted to Single Forwarder.
ZZ> Please add "IGMP/MLD" in front of "reports for (*,G1) or (S,G1)" in the
first sentence.

......
5.  Hot Standby Solution for Redundant G-Sources
ZZ> It's better to add a 'specification' sub-section for the solution procedure
description.

   1.  Configuration of the PEs
......
       Contrary to what is specified in the Warm Standby method (that is
       ......  The downstream PEs will locally select an Ethernet
       Segment Identifier for a given Single Flow Group, and will
       program a Reverse Path Forwarding check to the (*,G)/(S,G) state
       for the Single Flow Group that will discard (*,G)/(S,G) packets
       from the rest of the Ethernet Segment Identifiers.  The selection
       of the Ethernet Segment Identifier for the Single Flow Group is
       based on local policy.
ZZ> So different downstream PEs may select different upstream PE, this may be
described explicitly in the paragraph.

......
   3.  Distribution of DCB (Domain-wide Common Block) ESI-labels and
       G-source ES routes
......
       b.  The EVPN A-D per EVI and A-D per ES routes MUST include the
           route target SBD-RT since they have to be imported by all the
           PEs in the tenant domain.
ZZ> Since the SBD may not existed, please add "if the SBD exists" to indicate.

......
5.3.  Hot Standby Example in an OISM Network
......
   2.  PE1 and PE2 advertise S-PMSI A-D (*,G1) and EVPN ES, A-D per ES
       and A-D per EVI routes

       Based on the configuration of step 1, PE1 and PE2 advertise an
       S-PMSI A-D (*,G1) route each.  The route from each of the two PEs
       will include TWO ESI Label Extended Communities with ESI-1 and
       ESI-2 respectively, as well as route target BD1-RT plus SBD-RT
       and a flag that indicates that (*,G1) is a Single Flow Group.
ZZ> Same with previous comments, please replace "a flag" with "SFB flag".
And in the sentence
      'The route from each of the two PEs
       will include TWO ESI Label Extended Communities with ESI-1 and
       ESI-2 respectively,'
please use lower case for the "TWO", if it has no special meaning.

[End of Review]