BGP PIC HLD

[eddieruan-alibaba]

PR	Status	Submitters
[preview]Add PIC support in the srv6 VPN scenario. #16879		Zice, Alibaba
zebra: add an approach to keep the NHG ID unchanged for recursive rou… #16693		xingrenwai , Accton

[pguibert6WIND]

I think you should specify what you mean by "these changes do not affect the reachability ...".
I have 2 use cases in mind:

• UCMP - weighted extended community",
• route-map configured that look for the IGP metric, will be ignored.

[eddieruan-alibaba]

Let me update the wording. I mean the case BGP NH reachability would not be changed when IGP NHG updates. zebra needs to check BGP NH's reachability and skip BGP NHG update if all members's reachability is not changed.

Currently, the update is reported back to BGP and trigger BGP update even BGP NH's reachability is unchanged.

[pguibert6WIND]

thanks Eddie

[pguibert6WIND]

Some questions (to clarify)
more will come before next Tuesday (for frr meeting).
thanks.

Can you clarify the use case: is it for ebgp single hop and multi hop ?

[eddieruan-alibaba]

we use eBGP for underlay peering and MP-BGP for overlay peering with remote PE.

[eddieruan-alibaba]

Suggested by FRR folks, I raised FRRouting/frr#14703 for tracking the discussions in FRR community.

[eddieruan-alibaba]

HLD's direct link is https://github.com/eddieruan-alibaba/SONiC/blob/eruan-pic/doc/bgp_pic/bgp_pic.md

[eddieruan-alibaba]

The new location is moved to doc/pic/

https://github.com/eddieruan-alibaba/SONiC/blob/eruan-pic/doc/pic/bgp_pic_edge.md

[eddieruan-alibaba]

This PR contains two HLD now

1. PIC core, a.ka. recursive route handling HLD
2. PIC edge

[zhangyanzhao]

@eddieruan-alibaba can you please add the code PRs to this HLD PR? Thanks.

[eddieruan-alibaba]

http://phoenixwing.com.cn/codes

[zhangyanzhao]

PRs are not merged, move to backlog

[venkit-nexthop]

Sorry, since I started in SONiC after this, I am still working my way up on some old HLDs.
The backwalk and updating each PIC NHG (that contains the affected forwarding nexthop) is clear. But what is not clear is, that one forwarding nexthop could result in multiple context nexthop (because it could resolve over ECMP IGP route).

So...

Forwarding NH1 (PE1) ------> Context NH1 + VPN-LABEL-OR-SIDLIST-1
Context NH2. + VPN-LABEL-OR-SIDLIST-1
Forwarding NH2 (PE2)-------> Context NH3 + VPN-LABEL-OR-SIDLIST-2

PIC NHG = { NH1, NH2 }

Now if PE1 goes down, and we update the PIC NHG to only have {NH2}. But the context NHG would contain 3 entries? How does the single entry in PIC NHG get associated with the right context NH and VPN information?

[eddieruan-alibaba]

Basically, VPN label would be in overlay, and would not be associated with IGP paths which is underlay.

For MPLS VPN case: the chain at ingress PE would be

VPN routes --> Overlay NH2 ( PE1, VPN CTX 1) --> resolve via IGP NHG ...
Overlay NH3 ( PE2, VPN CTX 1)

For PIC edge case, we
VPN routes --> ECMP Overlay NH2 --> resolve via IGP NHG ...
Overlay NH3
--> PIC CTX ( PE1, VPN CTX 1)
( PE2, VPN CTX 1)

a.k.a for convergence purpose, VPN CTX is separated from overlay NHGs which contains forwarding information only.

For SRv6 VPN case, we don't need to resolve overlay NH into underlay, since it goes tunnel interface concept. But for MPLS VPN case, overlay NH would be resolved via label path in underlay.

When a remote PE down, it would disable a path in overlay NH, ASIC would use some hints to associated overlay NH with VPN CTX. The hint could be position index, or Agg prefix ID which Cisco uses in SRv6 VPN SAI.

Overlay NH would point to underlay NHG in MPLS VPN case, a.k.a remote PE down would not impact underlay NHG.