[RTG-DIR] Rtgdir early review of draft-ietf-mpls-mldp-multi-topology-05

Mike McBride via Datatracker <noreply@ietf.org> Mon, 06 May 2024 06:51 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 301F7C151069; Sun, 5 May 2024 23:51:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mike McBride via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-mpls-mldp-multi-topology.all@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171497828318.53963.3209477271871968947@ietfa.amsl.com>
Reply-To: Mike McBride <mmcbride7@gmail.com>
Date: Sun, 05 May 2024 23:51:23 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/k0mxWQkw0b2736LHf0pt9cAVABU>
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-mpls-mldp-multi-topology-05
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2024 06:51:23 -0000

Reviewer: Mike McBride
Review result: Has Nits

The following edits make the document more readable/understandable to me:

Abstract

Existing:
This document specifies extensions to mLDP to support MTR with FA such that
when building a Multipoint LSPs(Label Switched Paths) it can follow a
particular topology and algorithm.

Better:
This document specifies extensions to mLDP to support MTR, with FA, in order
for Multipoint LSPs(Label Switched Paths) to follow a particular topology and
algorithm.

4.  MT Scoped mLDP FECs

Existing:
The same applies to the IPA. The IPA needs to be encoded as part of the mLDP
FEC to create unique MP-LSPs and at the same time is used to signal to mLDP
(hop-by-hop) which Algorithm needs to be used to create the MP-LSP.

Better:
The same applies to the IPA. The IPA needs to be encoded as part of the mLDP
FEC to create unique MP-LSPs. The IPA is also used to signal to mLDP
(hop-by-hop) which Algorithm needs to be used to create the MP-LSP.

6.1.  Typed Wildcard MP FEC Elements

Existing:
The MT extensions proposed in document do not require any extension in
procedures for Typed Wildcard FEC Element support [RFC5918], and these
procedures apply as-is to Multipoint MT FEC wildcarding. Like Typed Wildcard MT
Prefix FEC Element, as defined in [RFC7307], the MT extensions allow use of "MT
IP" or "MT IPv6" in the Address Family field of the Typed Wildcard MP FEC
element in order to use wildcard operations for MP FECs in the context of a
given (sub)-topology as identified by the MT-ID and IPA field.

Better:
The MT extensions, proposed in this document, do not require any extension to
procedures for Typed Wildcard FEC Element support [RFC5918] and these
procedures apply as-is to Multipoint MT FEC wildcarding. Similar to Typed
Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT extensions
allow use of "MT IP" or "MT IPv6" in the Address Family field of the Typed
Wildcard MP FEC element. This is done in order to use wildcard operations for
MP FECs in the context of a given (sub)-topology as identified by the MT-ID and
IPA field.

8.  LSP Ping Extensions

Existing:
The rules and procedures of using this new sub-TLV in an MPLS echo request
message are same as defined for P2MP/MP2MP LDP FEC Stack Sub-TLV in [RFC6425]
with only difference being that Root LSR address is now (sub-)topology scoped.

Better:
The rules and procedures of using this new sub-TLV in an MPLS echo request
message are the same as defined for P2MP/MP2MP LDP FEC Stack Sub-TLV in
[RFC6425]. The only difference is that the Root LSR address is now
(sub-)topology scoped.

10.  Security Considerations

Existing:
This extension to mLDP does not introduce any new security considerations
beyond that already apply to the base LDP specification [RFC5036], base mLDP
specification [RFC6388], and MPLS security framework [RFC5920].

Better (applied rather than apply):
This extension to mLDP does not introduce any new security considerations
beyond that already applied to the base LDP specification [RFC5036], base mLDP
specification [RFC6388], and MPLS security framework [RFC5920].