Hi Ketan
Responses in-line
On Tue, Nov 15, 2022 at 12:19 PM Ketan Talaulikar <ketant.ietf@xxxxxxxxx> wrote:
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 <noreply@xxxxxxxx> 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.
Gyan> Ok
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.
Gyan> Perfect Thanks
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.
Gyan> Reading my comment again I agree since BGP LS has its own AFI the comment is not applicable
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.
Gyan> I was referring to the NBI as the SDN / PCE controller or router which in the draft is the consumer peering to the PE being the producer. So I am referring to the producer to consumer peering but the producer side of the peering and how to configure the producer side I think should be in scope as far as redundancy and having at least 2 producers PE nodes peering to the consumer as a best practice. Also that each PE producer does not need to peer to the consumer but at least 2 for redundancy. I am referring to the BGP peering consumer design aspects and not the application consumer which is out of scope - agreed. Please review above related to BGP Consumer which is relevant as their are a bunch of ways to configure the BGP consumer colocated on the RR or dedicated router in the domain or could be setup a consumer node that eBGP connects to the domain and so sits in a separate AS and could be eBGP multihop peering to remote producer PE or direct eBGP peeing to the producer PE.
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.
Gyan> Agreed. Here I was trying to give an example of a migration scenario where you have multiple planes, ships in the night and how best to configure the BGP LS peering producer to BGP consumer which is in scope. So I think this can be a very relevant scenario that should be included in the draft.
Thanks,Ketan
Thank you
Gyan Mishra
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
