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

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

Maybe the text in my draft needs to be more clear, but my draft is referencing  [I-D.ietf-idr-tunnel-encaps] ; Yes, according to section 1.4 of [I-D.ietf-idr-tunnel-encaps], IPsec tunnel is out of its scope, that’s why my draft says it extends [I-D.ietf-idr-tunnel-encaps] to support IPsec tunnel;

So when I say “the BGP update of NLRI prefix C need to include a Tunnel Encap attr, which include two IPsec TLVs…”, it means the BGP update include a Tunnel Encap attr as specified in section-2 of [I-D.ietf-idr-tunnel-encaps], and this Tunnel Encap attr include two TLVs:

  *   TLV-1: Tunnel Type is 4 (I propose to reuse 4 for IPsec tunnel), TLV-1 contains following sub-TLV:
     *   Remote Endpoint (as specified in section 3.1 of [I-D.ietf-idr-tunnel-encaps]) : local IPsec tunnel endpoint address of advertising router
     *   remote-prefix : pA
     *   color (as specified in 3.4.2 of [I-D.ietf-idr-tunnel-encaps], but has new semantics for IPsec): A
  *   TLV-2: Tunnel Type is 4 , TLV-2 contains following sub-TLV:
     *   Remote Endpoint: local IPsec tunnel endpoint address of advertising router
     *   remote-prefix: pB
     *   color: B

hope this make things clearer

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

Hi,

I think that the references are a bit wrong. And the confusion may be not even your own fault,
but IETF process related.

I was looking for type 4 tunnel type in your normative reference but there is none.


[I-D.ietf-idr-tunnel-encaps]

              Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel

              Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11<https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11>

              (work in progress), February 2019.



The reference your text may be referring to is perhaps RFC5566 instead

since this is where type 4 for IPSec in Tunnel mode was defined. Different document.



Unfortunately 5566 relied on 5512 which is obsoleted now. And we never

concluded how any references to 5566 should be now handled.



1.4<https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11#section-1.4>.  Impact on RFC 5566<https://tools.ietf.org/html/rfc5566>





   [RFC5566] uses the mechanisms defined in [RFC5512<https://tools.ietf.org/html/rfc5512>].  While this

   document obsoletes [RFC5512<https://tools.ietf.org/html/rfc5512>], it does not address the issue of how to

   use the mechanisms of [RFC5566<https://tools.ietf.org/html/rfc5566>] without also using the Encapsulation

   SAFI.  Those issues are considered to be outside the scope of this

   document.



And [I-D.ietf-idr-tunnel-encaps] does not define anything for IPSec.



So bottom line based on the current definition of Tunnel Encapsulation

Attribute I am not sure where and how you want to provide the defined

herein extensions.



Therefor it is now hard to comment on encoding specifics of provided examples

for two IPSec tunnel signalling options till normative references are sorted out.



Thx,

RR.



On Fri, Mar 8, 2019 at 11:48 PM Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Sent: Friday, March 8, 2019 2:26 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Cc: idr@ietf. org <[e-mail]<mailto:[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.