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

[Robert Raszuk <[e-mail]>]

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.