Skip to main content

Last Call Review of draft-ietf-idr-rfc7752bis-13
review-ietf-idr-rfc7752bis-13-opsdir-lc-mishra-2022-11-15-00

Request Review of draft-ietf-idr-rfc7752bis
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2022-11-14
Requested 2022-10-24
Authors Ketan Talaulikar
I-D last updated 2022-11-15
Completed reviews Rtgdir Last Call review of -11 by Joel M. Halpern (diff)
Opsdir Last Call review of -13 by Gyan Mishra (diff)
Opsdir Telechat review of -14 by Gyan Mishra (diff)
Intdir Telechat review of -14 by Brian Haberman (diff)
Assignment Reviewer Gyan Mishra
State Completed
Request Last Call review on draft-ietf-idr-rfc7752bis by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/s6M34GlgIyxdCNIA5AIegQoMzhY
Reviewed revision 13 (document currently at 17)
Result Not ready
Completed 2022-11-15
review-ietf-idr-rfc7752bis-13-opsdir-lc-mishra-2022-11-15-00
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