[Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13

Gyan Mishra via Datatracker <noreply@ietf.org> Tue, 15 November 2022 16:54 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4320BC1524C9; Tue, 15 Nov 2022 08:54:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Gyan Mishra via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-idr-rfc7752bis.all@ietf.org, idr@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166853127826.27308.14883176524823344383@ietfa.amsl.com>
Reply-To: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 15 Nov 2022 08:54:38 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-qMT-Oc-47YPvqTMQYKb_fzEyds>
Subject: [Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2022 16:54:38 -0000

Reviewer: Gyan Mishra
Review result: Not Ready

I reviewed the draft and I believe it is almost ready for publication.  I have
reviewed and provided comments over the progression of the draft on ML and I
think the draft is now close to ready for publication.

I have a handful of important final question for the author related to the
updates and additions I think that I think would improve the draft before
publication.

Will the change log section remain in the final publication or would that be
omitted.

Question related to BGP-LS and being able use for dynamic real time latency
metrics used for RSVP-TE ISIS metric extension RFC 8570 and RSVP-TE OSPF metric
extension RFC 7471 using OWAMP an STAMP RFC 8762 Performance measurements link
time stamp for unidirectional delay and 2 way delay as well as SR-PM being able
to use the same latency metrics.

I think this should be included in the draft update which I don’t see in the
RFC 7752.

Regarding next hop encoding section I think we should mention RFC 5565 softwire
mesh framework concept of single protocol core and 4to6 softwire sending IPv4
packets over an IPv6 core and 6to4 software sending IPv6 packets over and IPv4
core and the NBI interface and the next hop encoding to carry BGP LS NLRI over
an IPv6 core and IPv4 core and RFC 8950 next hop encoding as it applies to BGP
LS carrying IPv4 NLRI over an IPV6 core.  As BGP LS used a different AFI just
wanted to make sure the mix IPv4 NLRI over IPv6 next hop or IPv6 NLRI over IPV4
next hop does not come into play.

I don’t think this is mentioned in the draft but I think it’s important related
to the number of BGP-LS NBI peers necessary and the two options where the NBI
could be to a controller or multiple controllers within the same AS for
redundancy as well as the NBI could be a dedicated PCE router SBI that also
share the NBI and having redundancy for router or controller and at least two
peerings.  As well as mention that it is not necessary for the NBI exist to all
PEs and only one NBI to one PE in the AS at a minimum but better to have at
least 2 for redundancy.  As well as the NBI can be setup iBGP and the RR can
double up as PCE/BGP-LS node SBI & NBI or you can have the controller or router
SBI/NBI sitting in a separate AS and eBGP multihop to two PEs NBI session for
redundancy.

In cases of migration where you have full overlay any permutations of MPLS,
SR-MPLS, SRv6 and the core is dual stacked and not single protocol and so you
have a dual plane or multi plane core the caveats related to the NBI BGP-LS
peering and that you should for redundancy 2 NBI peers per plane for example
IPv4 peer for SR-MPLS IPv4 plane NabI and IPv6 peer for SRv6 plane NBI.

Thank you

Gyan Mishra