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

[Robert Raszuk <[e-mail]>]

Ok that was not very clear from the draft. While your explanation is good -
there may be folks who will try to include all remote prefixes as this
sub-TLV is mandatory. I guess if instead of all zero's you make it also
optional the room for bad encoding becomes smaller.

But let's assume that you have two different IPSec encapsulation
requirements A & B for the same local prefix C and two different remote
prefixes pA & pB.

How would you encode it in the single update msg ?

Thx,
R.

On Fri, Mar 8, 2019 at 10:31 PM Hu, Jun (Nokia - US/Mountain View) <
[e-mail]> wrote:

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