Hi Gyan,
I am trimming to only retain the open points below. Please check inline with KT2.
On Wed, Nov 16, 2022 at 8:33 AM Gyan Mishra <hayabusagsm@xxxxxxxxx> wrote:
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.
KT2> I am sorry, but your use of the term NBI is still not clear to me and there is no such term in the document. The discussion would be a lot easier if you were to use the terms in the documents. For now, I will assume that whenever you say "consumer" you are referring to the BGP-LS Consumer as defined in Sec 3 of the document. If this is not your intention, then is it possible for you to rephrase your comment?
So I am referring to the producer to consumer peering
KT2> BGP-LS Consumer is not a BGP Speaker and the interface to such consumer is outside the scope of this document.
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.
KT2> If your point is to capture redundancy aspects of the BGP-LS deployment design, we can perhaps add the following text in Sec 8.1.1.
It is RECOMMENDED that operators deploying BGP-LS enable at least two
or more BGP-LS Producers in each IGP flooding domain to achieve
redundancy in the origination of link-state information into BGP-LS.
It is also RECOMMENDED that operators ensure BGP peering designs that
ensure redundancy in the BGP update propagation paths (e.g., using at
least a pair of route reflectors) and ensuring that BGP-LS Consumers are
receiving the topology information from at least two BGP-LS Speakers.
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.
KT2> The choice of IPv4 or IPv6 for BGP-LS sessions has no impact on the topology information that is being carried in BGP-LS updates.
Thanks,
Ketan
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
