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

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

I agree that making remote prefix sub-TLV optional and absence of it means ANY is a better idea, will update the draft and example in it;

To address use case in your email, the BGP update of NLRI prefix C need to include a Tunnel Encap attr, which include two IPsec TLVs:

  *   IPsec TLV-1: include remote-prefix sub-TLV pA and color sub TLV A
  *   IPsec TLV-2: include remote-prefix sub-TLV pB and color sub TLV B



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


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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, March 8, 2019 12:49 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Cc: idr@ietf. org <[e-mail]<mailto:[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.