Re: [Idr] Further discussions on draft-sajassi-bess-secure-evpn &draft-dunbar-idr-sdwan-port-safi address (second attempt)

Susan Hares <shares@ndzh.com> Thu, 28 March 2019 08:15 UTC

From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Date: Thu, 28 Mar 2019 04:15:12 -0400
Message-ID: <5c9c8290.6fc.1018.32f6@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_SW_22605_1553760911_mpa="
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3w3PkfowN5cNhZv_H2T6XPuuf6k>
Subject: Re: [Idr] Further discussions on draft-sajassi-bess-secure-evpn &draft-dunbar-idr-sdwan-port-safi address (second attempt)
Precedence: list

[first attempt seem to bounce - resending. Sue]

Ali:

Thank you for quick summary.   Just a bit of additional context, since 
the IDR meeting today may be full.

<WG chair hat off, individual contributor hat on>

One places the registration step provides better handling of the 
gateways between VPNs.
[secure vpn-1] [gateway] [secure-vpn2]

Your step b: this case your  step b: signaling and set-up of the IPsec 
tunnel between C-PE and RR controller" works fine in the continuous 
VPN cae:


client1- (VPN2 for 1 segment)--client2

As I understand your solution (which may still be flawed), in the case 
of the gateway between two VPNs you require a the gateway box(es) to 
implement a entire virtual VPN instances.

Rather than make the gateway box implement "virtual vpn within a box" 
mechanisms (proposed by other vpn mechanisms), this utilizes sending 
the BGP NLRI (AFI/SAFI) to the RR with bootstrap data to allow the RR 
below.




(Diagram shows 1 RR, but it could be a group of RR+++).


     -------- RR---------
     |                         | BGP over TLS (due to security)
    R1-----tunnels---R2

to set-up tunnels between R1 and R2 using BGP tunnel attribute.

The bootstrap is used on initial set-up and upon dynamic change .

Linda's context was to help people understand where the 
VPN-gateway-VPN structure fit within SD-WAN.  This approach is 
different approach than existing gateway solutions (see bess drafts) 
and draft-hujun-idr-bgp-ipsec (single admin-domain).

A delightful re-reading of draft-idr-tunnel-encaps-11 indicates that 
technology may be stable enough for WG LC, but the text needs an 
editor's pen.   For example, I cannot confirm nor deny whether how the 
conflict of the MAC Addresses of section 4.2 of the 
draft-idr-tunnel-encaps-11.txt speaks of is resolved (precedence) if 
it conflict fluctuations.  This section is important because it speaks 
of the interaction for the gateway case described in 
(draft-ietf-bess-evpn-inter-subnet-forwarding) gateway.  The phrase 
"takes precedence" points the implementer in the right directions, but 
"seems" to conflict the text in section 11 (Error handling).


Keyur is going to present on updates to the tunnel draft at IDR.  I 
look forward to his presentation.


Sue
>
> --- Original message ---
> Subject: Further discussions on draft-sajassi-bess-secure-evpn 
> &draft-dunbar-idr-sdwan-port-safi address
> From: Ali Sajassi (sajassi) <sajassi@cisco.com>
> To: Idr <idr-bounces@ietf.org>
> Cc: Linda Dunbar <linda.dunbar@huawei.com>, Susan Hares 
> <shares@ndzh.com>, John E Drake <jdrake@juniper.net>, Ayan Banerjee 
> (ayabaner) <ayabaner@cisco.com>, David Carrel (carrel) 
> <carrel@cisco.com>, Ali Sajassi (sajassi) <sajassi@cisco.com>
> Date: Thursday, 28/03/2019 3:01 AM
>
>
>
> Hi folks,
>
> At the mic, I made a comment that the use cases being presented here 
> at the IDR session, were discussed previously between Linda and myself 
> and how secure-evpn draft can accommodate these use cases. When I made 
> this comment I had the following steps in mind: a) initial 
> configuration, b) signaling and setup of IPsec tunnel between C-PE and 
> RR/controller for BGP session, c) signaling of IPsec SAs among C-PE 
> (for carrying user traffic) over this secured BGP session using my 
> draft, and d) mapping of user traffic/flows from C-PE ingress ports to 
> these IPsec tunnels based on policy.
>
> Yesterday we had further discussions, and Linda/Sue are introducing 
> one additional step “port registration” before step-C above using 
> her draft. I had the question on why this step cannot be done as part 
> of step (a) or maybe (c). From my perspective, I need to better 
> understand what this registration step is exactly doing and if it can 
> be done as part of (a) or (c). I think Linda and Sue will take a 
> closer look at tunnel-encap draft which is the foundation of my draft 
> to evaluate it for the registration step. Anyway, I promised to give a 
> short summary and this is as short as I can get ☺
>
> Cheers,
> Ali
>
>

Re: [Idr] Further discussions on draft-sajassi-be… Susan Hares