Re: [Idr] draft-hujun-idr-bgp-ipsec

["Hu, Jun (Nokia - US/Mountain View)" <[e-mail]>]

Thanks for reviewing the draft;
In your example (500 routers), R2 doesn’t necessary need to advertise 500 remote prefixes because if R2 doesn’t have 500 different types IPsec encapsulation requirements for the NLRI, what it could do it just include a single all-zero remote prefix, means traffic from any source destined to this NLRI should use this particular IPsec tunnel encapsulation config;  and I would expect using all-zero remote prefix would be the common use case;

From: Robert Raszuk <[e-mail]>
Sent: Friday, March 8, 2019 12:49 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]>
Cc: idr@ietf. org <[e-mail]>
Subject: draft-hujun-idr-bgp-ipsec

Hi,

I have read your proposal and have one question.

The proposed encoding of additional sub-TLVs define local and remote prefixes as traffic selectors. Looks great in your example of two end points only. But introduction talks about scale so let's consider scale factor.

Assume you have 500 routers in the domain.

When you advertise subnet B or C from R2 now you need to include in mandatory Remote prefix sub-TLV 500 ingress prefixes as for each subnet advertised you can only send it once in BGP. Then each ingress PE receiving this huge list would need now to store all 500 ingress ACLs (mappings to IPSec tunnels) where in fact perhaps realistically only one or two ingress traffic subnets may ever be traversing via given edge router.

And 500 is just following your example where ingress prefixes are directly attached to ingress router (subnet A to R1). There can be valid mapping cases where such sources are not directly attached.

This really does not look at all efficient and is prone to generate a lot of unnecessary state directly proportional to network size or expected incoming src prefix number.

If you really would like to use p2mp protocol for this configuration push I would recommend to leave the current Tunnel Encapsulation Attribute unchanged and simply propose to define a new SAFI with proper NLRI syntax that it is precisely efficient to the very application you describe.

Effectively what you are proposing is to carry in BGP src+dst based mapping to IPSec tunnel deeply embedding this into sub-TLVs of tunnel encapsulation attribute.

In principle I agree that we do see more and more use cases for src+dst based IP lookups both for native forwarding and with some form of encapsulation but the proposed nested and not efficient encoding IMO requires to be modified to work well in the assumed large scale.

Thx a lot,
R.