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

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jun 2019 20:09:18 +0000

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.

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

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

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

-----------------
More are in the document:  https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/

We look forward to comments, suggestions and objections.

Thank you very much.

Linda

-----Original Message-----
From: rtgwg <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, June 19, 2019 2:57 PM
To: [email-masked]
Cc: [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

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://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

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

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/

_______________________________________________
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

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Jun 2019 19:11:06 +0000

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

-       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

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

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

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

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

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

Abstract:

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

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: Linda Dunbar <[email-masked]>
Date: Thu, 20 Jun 2019 22:07:38 +0000

John,

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

From: John E Drake <[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%2Ftools.ietf.org%2Fhtml%2Fdraft-sajassi-bess-secure-evpn-01&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C28557a27c1c64de4997708d6f5b30f7f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636966546754208641&sdata=qLd2LVx5Lng7QccAIB0weIfpXE3IBOQfq0kiLUJqFMs%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

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Jun 2019 22:49:44 +0000

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]>
Sent: Thursday, June 20, 2019 6:08 PM
To: John E Drake <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

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://urldefense.proofpoint.com/v2/url?u=https-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&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=v-ZrS-NTEa3rPqhwNaoM5gNU8iL1zGd7DutDZaH0C4w&s=nivOMac2lUDvbaJX-GTBeiLAWMqfyKOsTpqvG3AB27A&e=>).  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

[JD]  See above

[JD]  See above

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 20 Jun 2019 23:07:47 +0000

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]>
Sent: Thursday, June 20, 2019 5:50 PM
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,

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,

[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%7C944aca0c6afc4b5223e708d6f5d199ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636966677919821937&sdata=1Qp5WaPz5IaGkNDjG%2B5AcmYePzW9fzHh3fpkmaJkBqw%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

[JD]  See above

[JD]  See above

Linda

---

From: John E Drake <[email-masked]>
Date: Fri, 21 Jun 2019 13:14:29 +0000

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.

Yours Irrespectively,

John

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

John,

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,

Yours Irrespectively,

John

Juniper Internal

John,

[JD]  See above

[JD]  See above

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 21 Jun 2019 15:25:38 +0000

John,

I am with you hoping that the Tunnel-encap authors can clarify more.
Based on the description of how the receivers of the Tunnel UPDATE msg add the Encapsulation Headers to client routes described in the Tunnel-Encap draft, it should be:

  *   If the "Remote endpoint" sub-TLV was present and containing the same address as the route itself, then the receivers of the Tunnel UPDATE would construct the encapsulation header with the Outer Destination Address equal to the "route itself" (which is carried in the Remote Endpoint sub-TLV).
I think this can be a serious problem.

  *   if the "Remote Endpoint" sub-TLV was not present, the receivers of the Tunnel UPDATE would assume the UPDATE originator's address as the Tunnel Remote end point.

If the processing behavior described above is NOT what the Tunnel-Encap draft intended, then the Tunnel-Encap draft needs to add text to clarify the description.

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,

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

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[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

[JD]  See above

[JD]  See above

Linda

---

From: John Scudder <[email-masked]>
Date: Wed, 26 Jun 2019 18:06:06 +0000

Linda, John,

Your discussion is premised on the assumption that the remote endpoint sub-TLV is optional. Consider this paragraph, from section 5:

   When the Tunnel Encapsulation attribute is carried in an UPDATE of
   one of the AFI/SAFIs specified in the previous paragraph, each TLV
   MUST have a Remote Endpoint sub-TLV.  If a TLV that does not have a
   Remote Endpoint sub-TLV, that TLV should be treated as if it had a
   malformed Remote Endpoint sub-TLV (see Section 3.1<https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-12#section-3.1>).

There’s both a MUST clause and directions to ignore the sub-TLV if the remote endpoint is missing. To me this seems clear without any changes to the draft.

Regards,

—John

On Jun 21, 2019, at 8:25 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

John,

  *   If the “Remote endpoint” sub-TLV was present and containing the same address as the route itself, then the receivers of the Tunnel UPDATE would construct the encapsulation header with the Outer Destination Address equal to the “route itself” (which is carried in the Remote Endpoint sub-TLV).

  *   if the “Remote Endpoint” sub-TLV was not present, the receivers of the Tunnel UPDATE would assume the UPDATE originator’s address as the Tunnel Remote end point.

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

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

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

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.

Linda

Linda,

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

outside the scope of this document.”

Yours Irrespectively,

John

Juniper Internal

John,

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

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

[JD]  See above

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

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

[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

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=iOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0&s=oVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM&e=

---

From: John E Drake <[email-masked]>
Date: Wed, 26 Jun 2019 18:26:54 +0000

John,

Oopsie, I missed that.  Do we really want to have this behavior?  Having it optional would give us a lot more flexibility and I thought an attribute was supposed to be associated with a route.  Making the Remote Endpoint sub-TLV mandatory effectively associates the attribute with the remote endpoint.

Yours Irrespectively,

John

Juniper Business Use Only
From: John Scudder <[email-masked]>
Sent: Wednesday, June 26, 2019 2:06 PM
To: Linda Dunbar <[email-masked]>; John E Drake <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda, John,

There's both a MUST clause and directions to ignore the sub-TLV if the remote endpoint is missing. To me this seems clear without any changes to the draft.

Regards,

-John

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[JD]  See above

[JD]  See above

Linda

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Jun 2019 20:32:22 +0200

John,

> Making the Remote Endpoint sub-TLV mandatory effectively associates the
attribute with the remote endpoint.

I am not sure why you draw such conclusion.

Including remote endpoint address does not bind this sub-TLV to be
advertised with the remote end point NLRI. Quite contrary this information
is needed on a per NLRI basis.

How could you not send endpoint address if the entire purpose of this
extension is to signal the address where the encapsulation should be
terminated at - no ?

Thx,
R.

On Wed, Jun 26, 2019 at 8:27 PM John E Drake <jdrake=
[email-masked]> wrote:

> John,
>
>
>
> Oopsie, I missed that.  Do we really want to have this behavior?  Having
> it optional would give us a lot more flexibility and I thought an attribute
> was supposed to be associated with a route.  Making the Remote Endpoint
> sub-TLV mandatory effectively associates the attribute with the remote
> endpoint.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* John Scudder <[email-masked]>
> *Sent:* Wednesday, June 26, 2019 2:06 PM
> *To:* Linda Dunbar <[email-masked]>; John E Drake <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in
> draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
>
>
>
> Linda, John,
>
>
>
> Your discussion is premised on the assumption that the remote endpoint
> sub-TLV is optional. Consider this paragraph, from section 5:
>
>
>
>    malformed Remote Endpoint sub-TLV (see Section 3..1 <https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-12#section-3.1>).
>
>
>
> There’s both a MUST clause and directions to ignore the sub-TLV if the
> remote endpoint is missing. To me this seems clear without any changes to
> the draft.
>
>
>
> Regards,
>
>
>
> —John
>
>
>
> On Jun 21, 2019, at 8:25 AM, Linda Dunbar <[email-masked]>
> wrote:
>
>
>
> John,
>
>
>
> Based on the description of how the receivers of the Tunnel UPDATE msg add
> the Encapsulation Headers to client routes described in the Tunnel-Encap
> draft, it should be:
>
>    - If the “Remote endpoint” sub-TLV was present and containing the same
>    address as the route itself, then the receivers of the Tunnel UPDATE would
>    construct the encapsulation header with the Outer Destination Address equal
>    to the “route itself” (which is carried in the Remote Endpoint sub-TLV).
>
>    - if the “Remote Endpoint” sub-TLV was not present, the receivers of
>    the Tunnel UPDATE would assume the UPDATE originator’s address as the
>    Tunnel Remote end point.
>
>
>
> If the processing behavior described above is NOT what the Tunnel-Encap
> draft intended, then the Tunnel-Encap draft needs to add text to clarify
> the description.
>
>
>
> - 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.
>
>
>
> *From:* Linda Dunbar <[email-masked]>
> *Sent:* Thursday, June 20, 2019 7:08 PM
> *To:* John E Drake <[email-masked]>; [email-masked]; [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.
>
>
>
> *From:* John E Drake <[email-masked]>
> *Sent:* Thursday, June 20, 2019 5:50 PM
> *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,
>
>
>
> *From:* Linda Dunbar <[email-masked]>
> *Sent:* Thursday, June 20, 2019 6:08 PM
> *To:* John E Drake <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in
> draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
>
>
>
> John,
>
>
>
> *From:* John E Drake <[email-masked]>
> *<Snip> *
>
>
>
> -       [Tunnel-Encap] doesn’t have the functionality that would help the
> C-PE to register its WAN Port properties.
>
>
>
> -       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
> <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.*
>
>
>
>
>
> 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 *
>
>
>
> -       [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 *
>
>
>
> -       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.*
>
>
>
> *[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*
>
>
>
> [email-masked]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: John E Drake <[email-masked]>
Date: Wed, 26 Jun 2019 21:06:31 +0000

Robert,

As I understand it, the sub-TLV only became mandatory in the -12 version of the draft.  Comment inline.

Yours Irrespectively,

John

Juniper Business Use Only
From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, June 26, 2019 2:32 PM
To: John E Drake <jdrake=[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>; [email-masked]
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

> Making the Remote Endpoint sub-TLV mandatory effectively associates the attribute with the remote endpoint.

Including remote endpoint address does not bind this sub-TLV to be advertised with the remote end point NLRI. Quite contrary this information is needed on a per NLRI basis.

How could you not send endpoint address if the entire purpose of this extension is to signal the address where the encapsulation should be terminated at - no ?

[JD] You could issue an UPDATE for the tunnel endpoint itself which contained the tunnel encapsulation attribute sans an endpoint sub-TLV.  Any routes that use that tunnel endpoint would also include the tunnel encapsulation attribute that contains only the endpoint sub-TLV.

Thx,
R.

On Wed, Jun 26, 2019 at 8:27 PM John E Drake <jdrake=[email-masked]<mailto:[email-masked]>> wrote:
John,

Yours Irrespectively,

John

Juniper Business Use Only
From: John Scudder <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 26, 2019 2:06 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda, John,

   malformed Remote Endpoint sub-TLV (see Section 3..1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dtunnel-2Dencaps-2D12-23section-2D3.1&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q&s=1dbuCL3WFhEoWoXW5XxAEW2M1XfSEbTAqXS0ywCbiQQ&e=>).

Regards,

-John

John,

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

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[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

[JD]  See above

[JD]  See above

Linda

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q&s=A8YC23q254QuastVey6oWZfVPBsb8n8F-hi4hmH3jxA&e=>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Jun 2019 23:28:23 +0200

> *[JD] You could issue an UPDATE for the tunnel endpoint itself which
> contained the tunnel encapsulation attribute sans an endpoint sub-TLV.  *
>

What next would this UPDATE contain ?

See there seems to be already a provision for what I think you are trying
to do by this special case from section 3.1:

   There is one special case: the Remote Endpoint sub-TLV MAY have a
   value field whose Address Family subfield contains 0.  This means
   that the tunnel's remote endpoint is the UPDATE's BGP next hop.  If
   the Address Family subfield contains 0, the Address subfield is
   omitted, and the Autonomous System number field is set to 0.

> *Any routes that use that tunnel endpoint would also include the tunnel
> encapsulation attribute that contains only the endpoint sub-TLV.*
>

Well one could argue that if you properly mark next hop with proper tunnel
encapsulation selection and tunnel endpoint address you would not need to
attach any tunnel attribute at all as simple BGP recursion will inherit the
properties of next hop carried prefixes are pointing to.

Thx.
R.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Jun 2019 21:46:24 +0000

John and the Tunnel-Encap authors:

The following text on page 9 of Section 3.1 states that Remote sub-TLV can have NULL (0).

It seems to me that this paragraph contradicts to the statement that "Remote sub-TLV" must be present. Why can't receivers assume the "the tunnel's remote endpoint is the UPDATE's BGP next hop" if the remote sub-TLV is not present?

Another question: which of the following interpretation of the above paragraph is correct?
 "tunnel's remote endpoint is the UPDATE's BGP netxt hop" == "tunnel's remote endpoint is the originating node of the UPDATE message"
Or
"tunnel's remote endpoint is the UPDATE's BGP netxt hop" == "tunnel's remote endpoint is the next hop for the routes indicated in the received UPDATE message"

Thank you.

Linda

From: John E Drake <[email-masked]>
Sent: Wednesday, June 26, 2019 4:07 PM
To: Robert Raszuk <[email-masked]>; John E Drake <jdrake=[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>; [email-masked]
Subject: RE: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Robert,

Yours Irrespectively,

John

Juniper Business Use Only
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Wednesday, June 26, 2019 2:32 PM
To: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

Thx,
R.

Yours Irrespectively,

John

Linda, John,

   malformed Remote Endpoint sub-TLV (see Section 3..1<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dtunnel-2Dencaps-2D12-23section-2D3.1%26d%3DDwMFaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3D_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q%26s%3D1dbuCL3WFhEoWoXW5XxAEW2M1XfSEbTAqXS0ywCbiQQ%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979167213&sdata=LKgr8MtgyRjKGLNsbTpsHJhtMKTlp%2FgrduzG%2FobwH60%3D&reserved=0>).

Regards,

-John

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[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%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979177206&sdata=M5ZJeRk%2BZoGGRC3QYbrL2wp4FaOm28tluMms%2FwoNDG8%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

[JD]  See above

[JD]  See above

Linda

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=iOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0&s=oVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM&e=<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwICAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3DiOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0%26s%3DoVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979177206&sdata=8opRg4Sct13ndropCRP%2FEG425SYo4tK%2BozZuibf%2FR3s%3D&reserved=0>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwMFaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3D_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q%26s%3DA8YC23q254QuastVey6oWZfVPBsb8n8F-hi4hmH3jxA%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979187200&sdata=DE4J2klz6pzFkvXHIji%2BZWOkhSh3bCNXLL6NCPbxkJ0%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Jun 2019 23:55:20 +0200

Hi Linda,

> Why can’t receivers assume the “the tunnel’s remote endpoint is the
UPDATE’s BGP
> next hop” if the remote sub-TLV is not present?

The way I read John's S. comment he was not to question that. His point was
that if tunnel attribute *is* present it must contain Remote Endpoint
Sub-TLV. AF=0 still does not make this sub-TLV not to be present.

There is nothing in the spec however which would stop basic recursion to
work including recursion via next hop which can be reached via some form of
encapsulation.

Thx,
R.

On Wed, Jun 26, 2019 at 11:46 PM Linda Dunbar <[email-masked]>
wrote:

> It seems to me that this paragraph contradicts to the statement that
> “Remote sub-TLV” must be present. Why can’t receivers assume the “the
> tunnel’s remote endpoint is the UPDATE’s BGP next hop” if the remote
> sub-TLV is not present?
>
>
>
>  “tunnel’s remote endpoint is the UPDATE’s BGP netxt hop” == “tunnel’s
> remote endpoint is the originating node of the UPDATE message”
>
> Or
>
> “tunnel’s remote endpoint is the UPDATE’s BGP netxt hop” == “tunnel’s
> remote endpoint is the next hop for the routes indicated in the received
> UPDATE message”
>
>
>
>
>
> Thank you.
>
>
>
> Linda
>
>
>
>
>
> *Sent:* Wednesday, June 26, 2019 4:07 PM
> *To:* Robert Raszuk <[email-masked]>; John E Drake <jdrake=
> [email-masked]>
> *Cc:* [email-masked]; Linda Dunbar <[email-masked]>;
> [email-masked]
> *Subject:* RE: [Idr] Tunnel-Encap Gaps for SD-WAN described in
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 2:32 PM
> *To:* John E Drake <jdrake=[email-masked]>
> *Cc:* [email-masked]; Linda Dunbar <[email-masked]>;
> [email-masked]
> contained the tunnel encapsulation attribute sans an endpoint sub-TLV.  Any
> routes that use that tunnel endpoint would also include the tunnel
> encapsulation attribute that contains only the endpoint sub-TLV. *
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>    malformed Remote Endpoint sub-TLV (see Section 3..1 <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dtunnel-2Dencaps-2D12-23section-2D3.1%26d%3DDwMFaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3D_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q%26s%3D1dbuCL3WFhEoWoXW5XxAEW2M1XfSEbTAqXS0ywCbiQQ%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979167213&sdata=LKgr8MtgyRjKGLNsbTpsHJhtMKTlp%2FgrduzG%2FobwH60%3D&reserved=0>).
>
>
>
> reflect what has been discussed in this email thread....
>
>
>
> Linda
>
>
>
> <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%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979177206&sdata=M5ZJeRk%2BZoGGRC3QYbrL2wp4FaOm28tluMms%2FwoNDG8%3D&reserved=0>).
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwICAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3DiOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0%26s%3DoVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979177206&sdata=8opRg4Sct13ndropCRP%2FEG425SYo4tK%2BozZuibf%2FR3s%3D&reserved=0>
>
>
>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwMFaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3D_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q%26s%3DA8YC23q254QuastVey6oWZfVPBsb8n8F-hi4hmH3jxA%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C960739b0a07b46d1dec508d6fa7a2c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971799979187200&sdata=DE4J2klz6pzFkvXHIji%2BZWOkhSh3bCNXLL6NCPbxkJ0%3D&reserved=0>
>
>

---

From: John Scudder <[email-masked]>
Date: Wed, 26 Jun 2019 22:16:40 +0000

(As a WG member. I don’t speak from any authority, other than “a person who has read the spec several times and worked with implementors”.)

> On Jun 26, 2019, at 2:46 PM, Linda Dunbar <[email-masked]> wrote:
> 
> It seems to me that this paragraph contradicts to the statement that “Remote sub-TLV” must be present.

I don’t understand how that is a contradiction. A remote address sub-tlv with remote endpoint field value of 0 clearly IS a case of the sub-tlv being present — there is no field to be 0 if the sub-tlv isn’t present! The semantics of the 0 field are well-defined. There seems to be no contradiction to me.

> Why can’t receivers assume the “the tunnel’s remote endpoint is the UPDATE’s BGP next hop” if the remote sub-TLV is not present?

… because the spec doesn’t say that? 

Of course, the spec could (even at this late date) be changed to permit that behavior, but I don’t see it bringing any benefit since those semantics are already defined using remote endpoint = 0. Furthermore, advertising the sub-tlv with remote endpoint = 0 has the merit that it makes it explicit the behavior is desired, vs. having it happen by accident if the sub-tlv is inadvertently omitted.

If you have a compelling case for needing to omit the remote endpoint sub-tlv and get the stated effects, instead of including it with value 0, please do share.
 
>  “tunnel’s remote endpoint is the UPDATE’s BGP netxt hop” == “tunnel’s remote endpoint is the originating node of the UPDATE message”
> Or 
> “tunnel’s remote endpoint is the UPDATE’s BGP netxt hop” == “tunnel’s remote endpoint is the next hop for the routes indicated in the received UPDATE message”

I think it’s unambiguously the latter, since “BGP next hop” is a term of art. One might say “BGP NEXT_HOP” except that’s not formally correct for MP-BGP, where the right thing would be “value of the Network Address of Next Hop field within the MP_REACH_NLRI attribute”. So the text should either stand as written (my preference) or if great precision is needed, it could say something like “tunnel’s endpoint is the value depicted in either the UPDATE’s Network Address of Next Hop field within the MP_REACH_NLRI attribute if present, or NEXT_HOP attribute otherwise.”

Apart from the plain reading of the text, the other reason I think the first interpretation is not correct is, how is a receiver supposed to know what “the originating node of the UPDATE message” is? Without specified procedures, that relate to fields within the message, it would be ambiguous.

Thanks,

—John

---

From: John Scudder <[email-masked]>
Date: Wed, 26 Jun 2019 22:16:43 +0000

On Jun 26, 2019, at 2:55 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

There is nothing in the spec however which would stop basic recursion to work including recursion via next hop which can be reached via some form of encapsulation.

Agreed.

—John

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Jun 2019 23:02:06 +0000

John,

Thank you very much for the explanation.

More questions are inserted below:

-----Original Message-----
[Snipped]

[Linda] That is a very good point. I am just curious if all other TLVs/subTLVs of BGP's UPDATEs must be present with value NULL (0) to emphasize that it is not accidently omitted?

If you have a compelling case for needing to omit the remote endpoint sub-tlv and get the stated effects, instead of including it with value 0, please do share.
[Linda] simply a shorter message body, not sure if it is compelling enough.

[Linda] Your statement is indeed much clearer. Thank you. When a Node-A constructs this Tunnel-Encap UPDATE for routes attached to Node-A, does it use its own address in the  “UPDATE’s Network Address of Next Hop field”?  Does it have the options of using Node-A’s “Loopback address”, or the address of one of the ports on Node-A’s ?
If another node, say Node-B constructs this Tunnel-Encap UPDATE on behalf of Node-A, will the address in the  “UPDATE’s Network Address of Next Hop field” same as the Node-A address?
Under what scenarios, the address in “Remote endpoint sub-TLV” is different from the ““UPDATE’s Network Address of Next Hop field”?

Apart from the plain reading of the text, the other reason I think the first interpretation is not correct is, how is a receiver supposed to know what “the originating node of the UPDATE message” is? Without specified procedures, that relate to fields within the message, it would be ambiguous.
[Linda] Isn’t the Source Address of the UPDATE message same as the originating node of the UPDATE message?

Thanks,

—John

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Jun 2019 01:09:15 +0200

>
>  I am just curious if all other TLVs/subTLVs of BGP's UPDATEs must be
> present with value NULL (0) to emphasize that it is not accidently omitted?
>

They do not need to be present with NULL (0) value, but no one is drawing
any conclusion on missing attributes. Here you still want to implicitly
take next hops and treat it as tunnel endpoint - as John mentioned that
could be possible if spec would define such behavior when tunnel attribute
is present and Remote Endpoint Sub-TLV is not there. But I am not sure
however if there is sufficient value to it.

[Linda] Isn’t the Source Address of the UPDATE message same as the
> originating node of the UPDATE message?
>

No. Think about going via RRs as a basic example.

Thx,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Jun 2019 23:13:51 +0000

Robert,

You said:

Isn’t the main purpose of Tunnel-Encap is to construct the UPDATE to indicate “next hop can be reached via some form of encapsulation”?
When you say “recursion”, does it mean the Tunnel-Encap UPDATE can be used to specify multiple encapsulation headers?

Linda

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, June 26, 2019 4:55 PM
To: Linda Dunbar <[email-masked]>
Cc: John E Drake <[email-masked]>; John E Drake <jdrake=[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

Hi Linda,

> Why can’t receivers assume the “the tunnel’s remote endpoint is the UPDATE’s BGP

The way I read John's S. comment he was not to question that. His point was that if tunnel attribute *is* present it must contain Remote Endpoint Sub-TLV. AF=0 still does not make this sub-TLV not to be present.

Thx,
R.

On Wed, Jun 26, 2019 at 11:46 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
John and the Tunnel-Encap authors:

It seems to me that this paragraph contradicts to the statement that “Remote sub-TLV” must be present. Why can’t receivers assume the “the tunnel’s remote endpoint is the UPDATE’s BGP next hop” if the remote sub-TLV is not present?

Thank you.

Linda

To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>

Robert,

Yours Irrespectively,

John

John,

Thx,
R.

Yours Irrespectively,

John

Linda, John,

   malformed Remote Endpoint sub-TLV (see Section 3..1<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dtunnel-2Dencaps-2D12-23section-2D3.1%26d%3DDwMFaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3D_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q%26s%3D1dbuCL3WFhEoWoXW5XxAEW2M1XfSEbTAqXS0ywCbiQQ%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C73d7759e5c2f42f1bd2308d6fa810363%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971829360857084&sdata=0mksSZNbbK41FWQJX16XYSWRaj3My7foQ%2BFd4uuvwiE%3D&reserved=0>).

Regards,

—John

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[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%7C73d7759e5c2f42f1bd2308d6fa810363%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971829360867078&sdata=2QpZ7jWdvnYFKWv9X4nWOmOu9odZswpGG4%2FVD%2B2tyl4%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

[JD]  See above

[JD]  See above

Linda

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=iOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0&s=oVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM&e=<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwICAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3DiOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0%26s%3DoVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C73d7759e5c2f42f1bd2308d6fa810363%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971829360867078&sdata=%2FuvLceL1qAJKIzXjjyoz0NWqbv6aS3MfgKYcvOGpsWU%3D&reserved=0>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwMFaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3D_zqphBlaANTkEVfQVx5NpmQ7-8RubppSD0iarWwp51Q%26s%3DA8YC23q254QuastVey6oWZfVPBsb8n8F-hi4hmH3jxA%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C73d7759e5c2f42f1bd2308d6fa810363%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636971829360877072&sdata=Gtm28wZsZ0up4wAuDjDzE2dcmMmsQLQcG7HJ3hC0Hvg%3D&reserved=0>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Jun 2019 23:16:34 +0000

[Linda] I meant to say that when the “Remote subTLV” is 0.
When RR constructs the Tunnel-Encap for a node A, the UPDATE will use A in the “Remote endpoint subTLV”, correct?

Thx,
R.

---

From: John Scudder <[email-masked]>
Date: Wed, 26 Jun 2019 23:23:42 +0000

(Still as an individual contributor of course.)

On Jun 26, 2019, at 4:02 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

[Linda] Your statement is indeed much clearer. Thank you.

You are welcome.

When a Node-A constructs this Tunnel-Encap UPDATE for routes attached to Node-A, does it use its own address in the “UPDATE’s Network Address of Next Hop field”?  Does it have the options of using Node-A’s “Loopback address”, or the address of one of the ports on Node-A’s ?

Since the draft doesn’t supply any special rules for how to construct the next hop field, I would say existing rules apply. Generally all the options you listed are fine in normal BGP so I don’t see why they wouldn’t be here, too.

If another node, say Node-B constructs this Tunnel-Encap UPDATE on behalf of Node-A,

I’m not sure what this means.

will the address in the “UPDATE’s Network Address of Next Hop field” same as the Node-A address?

See previous.

When the tunnel endpoint is disjoint from the router that originates the route carrying the tunnel-encap attribute. I think use cases are beyond the scope of the draft but it’s not hard to imagine one, for example a controller (or controller-like device) directing traffic towards an appliance that is capable of acting as a tunnel endpoint but doesn’t itself speak BGP.

(Maybe this is what you meant by “on behalf of Node-A”? If so I don’t think it’s very important what the next hop is set to, although I think the most obvious and transparent thing would be to set it to an address of Node-B and list Node-A in the remote endpoint sub-tlv.)

In BGP we have UPDATE messages and we have routes. UPDATE messages carry routes, but they aren’t the same as routes. Sometimes people talk about “forwarding UPDATEs” but that’s wrong. Routes are formally defined in RFC 4271 section 1.1:

   Route
      A unit of information that pairs a set of destinations with the
      attributes of a path to those destinations.  The set of
      destinations are systems whose IP addresses are contained in one
      IP address prefix carried in the Network Layer Reachability
      Information (NLRI) field of an UPDATE message.  The path is the
      information reported in the path attributes field of the same
      UPDATE message.

A route can, and does, travel across multiple BGP peering sessions, potentially from one edge of the Internet to the other. By contrast, an UPDATE message never travels farther than from one peer to the next.

So I guess we can say that the source address of the UPDATE message is the same as the originating node of the UPDATE message (or rather, the source address of the IP packet(s) carrying the TCP segment(s) that carry the UPDATE message is the same as an IP address of the originating node of the UPDATE message). But that has no guaranteed relevance to the *route* carried within the UPDATE message. To take a simple example, if the route is originated by PE1, sent to RR1, which sends it to RR2, which sends it to PE2, when PE2 considers the received UPDATE message, its source is RR2, but the originator of the route is PE1.

—John

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Jun 2019 01:32:36 +0200

Under what scenarios, the address in “Remote endpoint sub-TLV” is different
from the ““UPDATE’s Network Address of Next Hop field”?

> When the tunnel endpoint is disjoint from the router that originates the
route carrying the tunnel-encap attribute. I think use cases are beyond the
> scope of the draft but it’s not hard to imagine one, for example a
controller (or controller-like device) directing traffic towards an
appliance that is
> capable of acting as a tunnel endpoint but doesn’t itself speak BGP.

I can think of even more basic example .. when UPDATE crosses EBGP boundary
between N number of ASes. Next hop field will be rewritten while tunnel
endpoint will stay. For example for the purpose of providing end to end
transport any inter-as application :) .

On Thu, Jun 27, 2019 at 1:23 AM John Scudder <[email-masked]> wrote:

> On Jun 26, 2019, at 4:02 PM, Linda Dunbar <[email-masked]>
> wrote:
>
> When a Node-A constructs this Tunnel-Encap UPDATE for routes attached to
> Node-A, does it use its own address in the “UPDATE’s Network Address of
> Next Hop field”?  Does it have the options of using Node-A’s “Loopback
> address”, or the address of one of the ports on Node-A’s ?
>
>
> Since the draft doesn’t supply any special rules for how to construct the
> next hop field, I would say existing rules apply. Generally all the options
> you listed are fine in normal BGP so I don’t see why they wouldn’t be here,
> too.
>
> Under what scenarios, the address in “Remote endpoint sub-TLV” is
> different from the ““UPDATE’s Network Address of Next Hop field”?
>
>
> When the tunnel endpoint is disjoint from the router that originates the
> route carrying the tunnel-encap attribute. I think use cases are beyond the
> scope of the draft but it’s not hard to imagine one, for example a
> controller (or controller-like device) directing traffic towards an
> appliance that is capable of acting as a tunnel endpoint but doesn’t itself
> speak BGP.
>
> (Maybe this is what you meant by “on behalf of Node-A”? If so I don’t
> think it’s very important what the next hop is set to, although I think the
> most obvious and transparent thing would be to set it to an address of
> Node-B and list Node-A in the remote endpoint sub-tlv.)
>
> Apart from the plain reading of the text, the other reason I think the
> first interpretation is not correct is, how is a receiver supposed to know
> what “the originating node of the UPDATE message” is? Without specified
> procedures, that relate to fields within the message, it would be ambiguous.
> In BGP we have UPDATE messages and we have routes. UPDATE messages carry
> routes, but they aren’t the same as routes. Sometimes people talk about
> “forwarding UPDATEs” but that’s wrong. Routes are formally defined in RFC
> 4271 section 1.1:
>
>    Route
> A route can, and does, travel across multiple BGP peering sessions,
> potentially from one edge of the Internet to the other. By contrast, an
> UPDATE message never travels farther than from one peer to the next.
>
> So I guess we can say that the source address of the UPDATE message is the
> same as the originating node of the UPDATE message (or rather, the source
> address of the IP packet(s) carrying the TCP segment(s) that carry the
> UPDATE message is the same as an IP address of the originating node of the
> UPDATE message). But that has no guaranteed relevance to the *route*
> carried within the UPDATE message. To take a simple example, if the route
> is originated by PE1, sent to RR1, which sends it to RR2, which sends it to
> PE2, when PE2 considers the received UPDATE message, its source is RR2, but
> the originator of the route is PE1.
>
> —John
>

---

From: John Scudder <[email-masked]>
Date: Wed, 26 Jun 2019 23:40:16 +0000

On Jun 26, 2019, at 4:32 PM, Robert Raszuk <[email-masked]> wrote:
> 
> I can think of even more basic example .. when UPDATE crosses EBGP boundary between N number of ASes. Next hop field will be rewritten while tunnel endpoint will stay. For example for the purpose of providing end to end transport any inter-as application :) .

Good point.

—John

---

From: John Scudder <[email-masked]>
Date: Thu, 27 Jun 2019 02:18:56 +0000

(Just a plain old contributor)

Linda,

I understood Robert’s reply to refer to normal route recursion as we see in any BGP deployment and specified in RFC 4271 Section 5.1.3:

   The immediate next-hop address is determined by performing a
   recursive route lookup operation for the IP address in the NEXT_HOP
   attribute

So a straightforward (though not mandatory) deployment model for tunnel-encap could be to advertise a service route which is a host route, for example a loopback address of the advertising router, with an associated tunnel-encap attribute, let’s call this route H. All the other routes can be made to use that tunnel by advertising H as their BGP next hop. The recursive route resolution procedure (excerpt above) will result in packets for those routes being directed into the tunnel.

This is just a consequence of the normal operation of BGP, there is nothing special about tunnel-encaps.

—John

On Jun 26, 2019, at 4:13 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Robert,

You said:

Linda

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 26, 2019 4:55 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Hi Linda,

Thx,
R.

Thank you.

Linda

Robert,

Yours Irrespectively,

John

John,

Thx,
R.

Yours Irrespectively,

John

Linda, John,

   malformed Remote Endpoint sub-TLV (see Section 3..1<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Didr-2D2Dtunnel-2D2Dencaps-2D2D12-2D23section-2D2D3.1-2526d-253DDwMFaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DCRB2tJiQePk0cT-2Dh5LGhEWH-2Ds-5FxXXup3HzvBSMRj5VE-2526m-253D-5FzqphBlaANTkEVfQVx5NpmQ7-2D8RubppSD0iarWwp51Q-2526s-253D1dbuCL3WFhEoWoXW5XxAEW2M1XfSEbTAqXS0ywCbiQQ-2526e-253D-26data-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C73d7759e5c2f42f1bd2308d6fa810363-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636971829360857084-26sdata-3D0mksSZNbbK41FWQJX16XYSWRaj3My7foQ-252BFd4uuvwiE-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=PDUkXqC86TSeOudCF6tQDKMpOq4X35yj9U4jlGwDirg&s=JRT81C8C0bkHA6zLIj0XF4ZKDH6sVVB84GX47kSk7D0&e=>).

Regards,

—John

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[JD]  See above

[JD]  See above

Linda

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=iOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0&s=oVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.ietf.org-5Fmailman-5Flistinfo-5Fidr-2526d-253DDwICAg-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DhLt5iDJpw7ukqICc0hoT7A-2526m-253DiOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0-2526s-253DoVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM-2526e-253D-26data-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C73d7759e5c2f42f1bd2308d6fa810363-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636971829360867078-26sdata-3D-252FuvLceL1qAJKIzXjjyoz0NWqbv6aS3MfgKYcvOGpsWU-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=PDUkXqC86TSeOudCF6tQDKMpOq4X35yj9U4jlGwDirg&s=JKSaEfWrR4YxXMW-wSuHjNyNVgdF542ncvrm9kTyRf8&e=>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.ietf.org-5Fmailman-5Flistinfo-5Fidr-2526d-253DDwMFaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DCRB2tJiQePk0cT-2Dh5LGhEWH-2Ds-5FxXXup3HzvBSMRj5VE-2526m-253D-5FzqphBlaANTkEVfQVx5NpmQ7-2D8RubppSD0iarWwp51Q-2526s-253DA8YC23q254QuastVey6oWZfVPBsb8n8F-2Dhi4hmH3jxA-2526e-253D-26data-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C73d7759e5c2f42f1bd2308d6fa810363-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636971829360877072-26sdata-3DGtm28wZsZ0up4wAuDjDzE2dcmMmsQLQcG7HJ3hC0Hvg-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=PDUkXqC86TSeOudCF6tQDKMpOq4X35yj9U4jlGwDirg&s=EL59nSBxo_qfBZ21sJbCaZbiWFmCis0q3VETKOu_Zts&e=>
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=PDUkXqC86TSeOudCF6tQDKMpOq4X35yj9U4jlGwDirg&s=yxShMfrI_wmm845nOll-gQgnVWX2VktWJoRVw-Yaac8&e=

---

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

Robert, John:

First, I don’t see an issue with sending endpoint sub-TLV along with a route from underlay space. Second, [Tunnel-Encap] provides recursive resolution and coloring so that we don’t need to send the Tunnel Attribute with every VPN routes. Third, secure-evpn talks about route hierarchy for finer level of granularity of tunnel setup.

Robert, wrt section 3.1, I think this special case is in context of section 4.1.

Cheers,
Ali

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Wednesday, June 26, 2019 at 2:30 PM
To: John E Drake <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>, John E Drake <jdrake=[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

[JD] You could issue an UPDATE for the tunnel endpoint itself which contained the tunnel encapsulation attribute sans an endpoint sub-TLV.

See there seems to be already a provision for what I think you are trying to do by this special case from section 3.1:

Any routes that use that tunnel endpoint would also include the tunnel encapsulation attribute that contains only the endpoint sub-TLV.

Well one could argue that if you properly mark next hop with proper tunnel encapsulation selection and tunnel endpoint address you would not need to attach any tunnel attribute at all as simple BGP recursion will inherit the properties of next hop carried prefixes are pointing to.

Thx.
R.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 28 Jun 2019 05:07:30 +0000

From: Idr <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Wednesday, June 26, 2019 at 2:49 PM
To: John E Drake <[email-masked]>, Robert Raszuk <[email-masked]>, John E Drake <jdrake=[email-masked]>
Cc: "[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

[AS] It does not contract anything. It simply says that the value of it may be zero which means the tunnel endpoint is the same as BGP next hop. In other words, it still MUST be present when sending the attribute but the value may be zero.

-Ali

Thank you.

Linda

Robert,

Yours Irrespectively,

John

Cc: [email-masked]<mailto:[email-masked]>; Linda Dunbar <linda.dunbar@futurewei..com<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

John,

Thx,
R.

Yours Irrespectively,

John

Linda, John,

Regards,

—John

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 28 Jun 2019 06:40:37 +0000

From: Idr <[email-masked]> on behalf of John Scudder <jgs=[email-masked]>
Date: Wednesday, June 26, 2019 at 7:21 PM
To: Linda Dunbar <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, John E Drake <jdrake=[email-masked]>, Robert Raszuk <[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,

   attribute

[AS] Interesting enough, this is one of the thing I discussed with Linda during our face-to-face conversation at the last IETF which is also used in secure-evpn draft. Tunnel-Encap draft also provides an example of such recursiveness in section 7.

Cheers,
Ali

—John

Robert,

You said:

Linda

Hi Linda,

Thx,
R.

Thank you.

Linda

Robert,

Yours Irrespectively,

John

John,

Thx,
R.

Yours Irrespectively,

John

Linda, John,

Regards,

—John

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

Linda

Linda,

Yours Irrespectively,

John

Juniper Internal

John,

[JD]  See above

[JD]  See above

Linda

---

From: John Scudder <[email-masked]>
Date: Fri, 28 Jun 2019 15:23:34 +0000

On Jun 28, 2019, at 2:40 AM, Ali Sajassi (sajassi) <[email-masked]> wrote:
> 
> Tunnel-Encap draft also provides an example of such recursiveness in section 7.

Oh, right, of course. Thanks for pointing that out.

—John