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

[Ketan Talaulikar <[e-mail]>]

Hi Gyan,

Thanks for your review and please check inline below for responses.


On Tue, Nov 15, 2022 at 10:24 PM Gyan Mishra via Datatracker <
[e-mail]> wrote:

> 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.
>

KT> It would remain.


>
> 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.
>

KT> Those are already covered by RFC8571.


>
> 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.
>

KT> BGP-LS has its own AFI (16388) and so I am not sure that I understand
this comment.


>
> 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.
>

KT> I am not sure that I understand what exactly is meant by NBI here. The
document only talks about BGP. The interface/API between a BGP Speaker and
(consumer) applications is out of scope - whether it be an "external"
northbound API (e.g., via REST) or something "internal" IPC within a
router/system.


>
> 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.
>

KT> Please see my previous response clarifying the AFI for BGP-LS. As such,
I don't see how MPLS/SR-MPLS/SRv6 makes any difference here.

Thanks,
Ketan


>
> Thank you
>
> Gyan Mishra
>
>
>