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

[Gyan Mishra <[e-mail]>]

Hi Ketan

Responses in-line

On Tue, Nov 15, 2022 at 12:19 PM Ketan Talaulikar <[e-mail]>
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 <
> [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.
>

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*