Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 28 Jun 2019 00:26:55 +0000

Linda,

I am catching up with this email thread. You are making a lot of incorrect assumption about [tunnel-encap]. We had a two-hour discussions at the last IETF meeting and I explained many of these points. I will provide further clarifications as I go through this email thread. Please refer to my comments inline marked w/ [AS].

From: Idr <[email-masked]> on behalf of John E Drake <jdrake=[email-masked]>
Date: Thursday, June 20, 2019 at 12:13 PM
To: Linda Dunbar <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda,

Comments inline.

Yours Irrespectively,

John

Juniper Internal
From: Idr <[email-masked]> On Behalf Of Linda Dunbar
Sent: Wednesday, June 19, 2019 4:09 PM
To: [email-masked]; [email-masked]
Subject: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

We updated the gap analysis on using Tunnel-Encap for SD-WAN tunnel after some confusions in interpreting the Tunnel-Encap draft are cleared by the IDR's a long thread of email discussion. Many thanks to the IDR Chair and the participants for the discussion.

Here is the highlight of the gaps. We would appreciate greatly to hear comments or objections for our gap analysis.

-------------------------------------------

-       [Tunnel-Encap] doesn’t have the functionality that would help the C-PE to register its WAN Port properties.

[AS] What functionality is that ???  [Tunel-Encap] provides lot of flexibility:

  *   You can attached the attribute to VPNv4 or VPNv6 routes
  *   You can attach the attribute to IPv4 or IPv6 routes

·         You can do recursive resolutions and inherit tunnel attribute via such recursion

·         You can do coloring of VPN routes (instead of sending the attribute) and inherit the attribute info via such coloring

-       A SD-WAN tunnel, e.g. IPsec-based, requires a negotiation between the tunnel’s end points for supported encryption algorithms and tunnel types before it can be properly established, whereas [Tunnel-Encap]  only allow the announcement of one endpoint’s supported encapsulation capabilities for specific attached routes and no negotiation between tunnel end points is needed.

[JD]  What you need to do is implement the model described in  the Secure EVPN draft (https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-01).  Viz, the SD-WAN C-PEs are attached to a route reflector and each uses the route reflector to advertise its security-related  information the other C-PEs.  As we discussed in Prague the tunnel encapsulation attribute is not associated with client routes.  Rather it is associated with the loopback or interface addresses of the advertising SD-WAN C-PE.  I.e., IPv4/IPv6 addresses rather than VPN IPv4/IPv6 addresses

[AS] Furthermore, secure-evpn draft discusses how you can inherit the tunnel attribute via route hierarchy and specifies different level of hiearchcy.

The establishment of a SD-WAN tunnel can fail, e.g., in case the two endpoints support different encryption algorithms. That is why a SD-WAN tunnel needs to be established and maintained independently from advertising client routes attached to the edge node.

[JD]  See above

[AS] Tunnel is setup point-to-point whereas the signaling is done P2MP. I think this point is being missed.

-       [Tunnel-Encap] requires all tunnels updates are associated with routes. There can be many client routes associated with the SD-WAN IPsec tunnel between two C-PEs’ WAN ports; the corresponding destination prefixes (as announced by the aforementioned routes) may also be reached through the VPN underlay without any encryption.. A more realistic approach to separate SD-WAN tunnel management from client routes association with the SD-WAN tunnels.

[JD]  See above

[AS] That is incorrect. [Tunnel-Encap] does not require all VPN routes be sent with tunnel attribute. That’s why they have the notion of recursive route resolution and coloring exist in that draft. Furthermore, you can have multiple tunnels for the same pair of end-point tunnel addresses.

-       When SD-WAN tunnel and clients routes are separate, the SD-WAN Tunnel establishment may not have routes associated.
There is a suggestion on using a “Fake Route” for a SD-WAN node to use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points properties. However, using “Fake Route” can raise some design complexity for large SD-WAN networks with many tunnels. For example, for a SD-WAN network with hundreds of nodes, with each node having many ports & many endpoints to establish SD-WAN tunnels with their corresponding peers, the node would need as many “fake addresses”. For large SD-WAN networks (such as those comprised of more than 10000 nodes), each node might need 10’s thousands of “fake addresses”, which is very difficult to manage and requires lots of configuration tasks to get the nodes properly set up.

[JD]  There is no need for a ‘Fake Route’.  We advertise a tunnel encapsulation attribute with security-related information for a specific SD-WAN port on the C-PE as identified by its IPv4/IPv6 interface address.  If a set of SD-WAN ports have common security-related information a tunnel encapsulation attribute can be advertised with a C-PE’s loopback address.

[AS] Linda, [Tunnel-Encap] doesn’t require fake routes as the attribute can be attached to any updates – i.e., it can be attached to a WAN-port that is identified by IPv4 or IPv6 AFI/SAFI which is different from VPNv4  or VPNv6 routes.

Cheers,
Ali

-----------------
More are in the document: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Drtgwg-2Dnet2cloud-2Dgap-2Danalysis_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=svEApaK250yroEYlWy7i4KW3lGckXW5jGBoYG61yxjk&s=2rIUQFCJoAFnuwwnL1FIll46MZ2jNT4KwtrUUUbtLes&e=>

We look forward to comments, suggestions and objections.

Thank you very much.

Linda

-----Original Message-----
From: rtgwg <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, June 19, 2019 2:57 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Area Working Group WG of the IETF.

        Title           : Gap Analysis of Dynamic Networks to Hybrid Cloud DCs
        Authors         : Linda Dunbar
                          Andrew G. Malis
                          Christian Jacquenet
        Filename        : draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
        Pages           : 18
        Date            : 2019-06-19

Abstract:
   This document analyzes the technological gaps when using SD-WAN to
   dynamically interconnect workloads and applications hosted in
           rd        various 3  party cloud data centers.

The IETF datatracker status page for this draft is:
https://nam03.safelinks.protection.outlook..com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-gap-analysis%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C702c4feeabf74674d3a608d6f4f0601b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636965710579388472&amp;sdata=PxMtUZdFrkeIb5gh%2BBSXO5y3aOJ9GkTGIj5OHcKbzjk%3D&amp;reserved=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fdraft-2Dietf-2Drtgwg-2Dnet2cloud-2Dgap-2Danalysis-252F-26amp-3Bdata-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C702c4feeabf74674d3a608d6f4f0601b-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636965710579388472-26amp-3Bsdata-3DPxMtUZdFrkeIb5gh-252BBSXO5y3aOJ9GkTGIj5OHcKbzjk-253D-26amp-3Breserved-3D0&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=svEApaK250yroEYlWy7i4KW3lGckXW5jGBoYG61yxjk&s=TGSymHjjXxA_8Th-ecvreJ9bUSXRs5pTOjleBMame34&e=>

There are also htmlized versions available at:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rtgwg-net2cloud-gap-analysis-02&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C702c4feeabf74674d3a608d6f4f0601b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636965710579388472&amp;sdata=jJrKoSyeI%2FYl%2FVxwnC%2FWt2VrUs3z2cPyzEtJ2iv619M%3D&amp;reserved=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dietf-2Drtgwg-2Dnet2cloud-2Dgap-2Danalysis-2D02-26amp-3Bdata-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C702c4feeabf74674d3a608d6f4f0601b-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636965710579388472-26amp-3Bsdata-3DjJrKoSyeI-252FYl-252FVxwnC-252FWt2VrUs3z2cPyzEtJ2iv619M-253D-26amp-3Breserved-3D0&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=svEApaK250yroEYlWy7i4KW3lGckXW5jGBoYG61yxjk&s=nLzFbFuVnwaHhij5epTjrbhqItQ-GBgJC9-i8CMMh_w&e=>
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-rtgwg-net2cloud-gap-analysis-02&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C702c4feeabf74674d3a608d6f4f0601b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636965710579388472&amp;sdata=p1tOJDeZAfig110sJF5748r7w%2BuAxw2Id9XQyg4NUQY%3D&amp;reserved=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fhtml-252Fdraft-2Dietf-2Drtgwg-2Dnet2cloud-2Dgap-2Danalysis-2D02-26amp-3Bdata-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C702c4feeabf74674d3a608d6f4f0601b-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636965710579388472-26amp-3Bsdata-3Dp1tOJDeZAfig110sJF5748r7w-252BuAxw2Id9XQyg4NUQY-253D-26amp-3Breserved-3D0&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=svEApaK250yroEYlWy7i4KW3lGckXW5jGBoYG61yxjk&s=4uVaaPMwkhndws3rOU4mHn1xbtbBJbRoIJ9jIrBPW14&e=>

A diff from the previous version is available at:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-rtgwg-net2cloud-gap-analysis-02&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C702c4feeabf74674d3a608d6f4f0601b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636965710579388472&amp;sdata=rZyP0RdcQHkZvf1y0e8ZqCcuiHKlDSdfx4WlbYUfZeI%3D&amp;reserved=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Frfcdiff-253Furl2-253Ddraft-2Dietf-2Drtgwg-2Dnet2cloud-2Dgap-2Danalysis-2D02-26amp-3Bdata-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C702c4feeabf74674d3a608d6f4f0601b-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636965710579388472-26amp-3Bsdata-3DrZyP0RdcQHkZvf1y0e8ZqCcuiHKlDSdfx4WlbYUfZeI-253D-26amp-3Breserved-3D0&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=svEApaK250yroEYlWy7i4KW3lGckXW5jGBoYG61yxjk&s=9bc5wSdhJ_EpKMK4bzuSoIi_syNoQzq4R00pTiDM4ow&e=>

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=svEApaK250yroEYlWy7i4KW3lGckXW5jGBoYG61yxjk&s=qRWZ3qZdW0201EhLZzTqlvnUFWSJCPmtuIbcQP7NaXc&e=>

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C702c4feeabf74674d3a608d6f4f0601b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636965710579388472&amp;sdata=TXSGr8jvjQrSgaM9H6LDEudl9ZXk0%2BY1YTbZ%2BSvqZEk%3D&amp;reserved=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Frtgwg-26amp-3Bdata-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C702c4feeabf74674d3a608d6f4f0601b-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636965710579388472-26amp-3Bsdata-3DTXSGr8jvjQrSgaM9H6LDEudl9ZXk0-252BY1YTbZ-252BSvqZEk-253D-26amp-3Breserved-3D0&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=svEApaK250yroEYlWy7i4KW3lGckXW5jGBoYG61yxjk&s=KJL3raMv7Z5jRY7_dfcBiwO8H-3m-wRiD-X4XFzV-cs&e=>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 28 Jun 2019 00:54:24 +0000

Linda,

I do have an objection with such claims you make below that are not grounded. You can signal a WAN port directly as your tunnel endpoint (IPsec or not) or indirectly using scheme described in secure-evpn and [Tunnel-Encap]. You can setup different tunnel for different pair of tunnel endpoints or even setup multiple tunnels between a pair of tunnel endpoints  and use local policy to forward different client traffic to different tunnel.

-Ali

From: Idr <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Friday, June 21, 2019 at 8:29 AM
To: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

<snip>

Nevertheless, do you have objections of those gaps that Tunnel-Encap and Secure-EVPN:

- Doesn’t have the functionality that would help the C-PE to register its WAN Port properties. Some WAN ports are facing public internet with ISP assigned addresses that are in different address space than the SD-WAN address space, some WAN ports are assigned with private addresses which need to propagate NAT information to the trusted peers via Controllers, such as the virtual C-PEs instantiated in public Cloud DCs, and some WAN ports are facing the trusted MPLS network.

- For the same Client route, e.g. 10.1.x.x, attached to a C-PE, need to be encrypted when forwarding to the WAN ports facing untrusted network, and can be forwarded without any encryption towards WAN ports facing trusted network.

Thank you very much for the discussion. I have updated the Gap analysis to reflect what has been discussed in this email thread..

Linda

From: John E Drake <[email-masked]>
Sent: Friday, June 21, 2019 8:14 AM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda,

It would be useful to get a clarification from the authors.  I had always thought that if the remote endpoint sub-TLV was either not present or present and containing the same address as the route itself, then the information in the tunnel encapsulation attribute pertains to the address specified in the route.  This is the assumption made in the Secure EVPN draft that I mentioned earlier in this thread.

Alternatively, the route could specify a loopback address of the C-PE and the tunnel encapsulation attribute could contain the interface address and characteristics of each of its WAN-facing ports; this is completely compliant with your interpretation that the address specified in the route is reachable through an address specified in the remote endpoint sub-TLV.

[Linda] But there is no field to indicate the property of the WAN ports.

Yours Irrespectively,

John

Juniper Internal
From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 20, 2019 7:08 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

Those addresses stated in the quoted paragraphs are for Clients Routes, i.e. the routes attached to the PE, not the PE’s lookback address, correct?
The Loopback Address is specified in the “Remote Endpoint” SubTLV, so that receivers of the UPDATE can establish the Encapsulation with the outer destination address equal to the one specified by the “Remote endpoint” SubTLV.

That was discussed in the long email discussion thread last week.

We can ask the Tunnel-Encap authors to confirm.

Linda

From: John E Drake <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 20, 2019 5:50 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda,

From section 5 on the Tunnel Encapsulation Attribute draft:

“[RFC5512] specifies the use of the Tunnel Encapsulation attribute in
BGP UPDATE messages of AFI/SAFI 1/7 and 2/7.  That document restricts
the use of this attribute to UPDATE messsages of those SAFIs.  This
document removes that restriction.

The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
or 25/70 (Ethernet VPN, usually known as EVPN)).  Use of the Tunnel
Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
outside the scope of this document.”

What this means is that the tunnel encapsulation draft can be use exactly
as I described in my previous email to describe the characteristics of
of an SD-WAN port.

Yours Irrespectively,

John

Juniper Internal
From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 20, 2019 6:08 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

Thank you very much for the feedback.
Comments are inserted below:

From: John E Drake <[email-masked]<mailto:[email-masked]>>
<Snip>

[JD]  What you need to do is implement the model described in  the Secure EVPN draft (https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-01<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint..com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dsajassi-2Dbess-2Dsecure-2Devpn-2D01-26data-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C28557a27c1c64de4997708d6f5b30f7f-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C1-257C636966546754208641-26sdata-3DqLd2LVx5Lng7QccAIB0weIfpXE3IBOQfq0kiLUJqFMs-253D-26reserved-3D0%26d%3DDwMFAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3Dv-ZrS-NTEa3rPqhwNaoM5gNU8iL1zGd7DutDZaH0C4w%26s%3DnivOMac2lUDvbaJX-GTBeiLAWMqfyKOsTpqvG3AB27A%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C84c6ed1f7cb342efda1208d6f64a6827%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636967196777678003&sdata=3wnRuxLXyDo9qPVXcIfbGNWZMNC37wef0hd4kBJlEWQ%3D&reserved=0>).  Viz, the SD-WAN C-PEs are attached to a route reflector and each uses the route reflector to advertise its security-related  information the other C-PEs.  As we discussed in Prague the tunnel encapsulation attribute is not associated with client routes.  Rather it is associated with the loopback or interface addresses of the advertising SD-WAN C-PE.  I.e., IPv4/IPv6 addresses rather than VPN IPv4/IPv6 addresses

[Linda]Yes, using Loopback address would be a good way for tunnel, but that is not what Tunnel-Encap specified. The draft Tunnel-Encap is to advertise supported Encap capabilities for specified routes.
I have another section (4.3) on the gap analysis for SECURE-EVPN, specifically, Secure-EVPN does not address the scenario of C-PE having some ports facing trusted MPLS VPN and other ports facing the untrusted public Internet. The document assumes that a client route is either forwarded all encrypted through one tunnel, or not encrypted at all through a different tunnel. In SD-WAN, one client route can be forwarded encrypted at one time through the untrusted network and be forwarded unencrypted at different time through MPLS VPN.
If you think the secure-evpn has addressed those scenarios, can you please indicate which section? Thank you.

[JD]  See above

[JD]  See above

[Linda] this section is for Tunnel-Encap, which doesn’t allow Loopback address to be associated with the tunnel. If you think it does, can you please indicate which section? Thank you.

Linda