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

John Scudder <jgs@juniper.net> Thu, 27 June 2019 02:19 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187CC12002E; Wed, 26 Jun 2019 19:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgZL_jPwWm9L; Wed, 26 Jun 2019 19:19:07 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53551120152; Wed, 26 Jun 2019 19:19:07 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5R2EA2l030657; Wed, 26 Jun 2019 19:19:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=igx5WpoBRxEkyUidzlveniWuIcnPRz1oB90jvhlxwwY=; b=OUPDRd1Ep3N4P8r66ofqLETcL/0h7u3qJLD3kYMm22s/jkDGnmFuPJ81xNZ9VI797wDv H9tK/QPrID+/XfgQ56GHQAZQdpcE74d/ktJg6o47/ThprZiEY4NxxqmqHk5nv4zL2UhU 76xbVTD8+e7V56ZyBOZgVfIZKrtTaAVWd5gSzf0THMbxrMpqKwNIvsiqc1tgTg0wA8Nr MphD1TJxmW+cQOAyJx1R/RUiV38FRgDDQiVCixaSn9obOCRHA6T8kqCWU7U9qpKwPJyG 8g09Aw6YL7C1qsR1GQiyzX7NKKmZ/HaV1O0yguX19XaO0yjvbUpUCFTyt7Qz5eB8xQzR Zw==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp2053.outbound.protection.outlook.com [104.47.42.53]) by mx0a-00273201.pphosted.com with ESMTP id 2tcjt2061e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Jun 2019 19:18:59 -0700
Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.109.215) by DM6PR05MB4235.namprd05.prod.outlook.com (20.176.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.12; Thu, 27 Jun 2019 02:18:56 +0000
Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::1549:ffd0:8373:4593]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::1549:ffd0:8373:4593%3]) with mapi id 15.20.2032.012; Thu, 27 Jun 2019 02:18:56 +0000
From: John Scudder <jgs@juniper.net>
To: Linda Dunbar <linda.dunbar@futurewei.com>
CC: Robert Raszuk <robert@raszuk.net>, "idr@ietf.org" <idr@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
Thread-Topic: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
Thread-Index: AdUm2V3OpdsU1OeER3S07GObn2sxqQAuM8HQAAeqFDAAAhbNoAAAx2nAAB0KTXAAA76b8AECmC2AAACO5/AAAFwXAAAFHBggAAE65kAAAL+sAAACkYSQAAajGoA=
Date: Thu, 27 Jun 2019 02:18:56 +0000
Message-ID: <1BB37B3A-67A6-4DBD-B774-017F6AE41B77@juniper.net>
References: <MN2PR13MB358267E50BCEB2E7795046B785E50@MN2PR13MB3582.namprd13.prod.outlook.com> <BYAPR05MB5029672CA347E6EC1B94E476C7E40@BYAPR05MB5029.namprd05.prod.outlook.com> <MN2PR13MB358228DB2D7DD56204660F6985E40@MN2PR13MB3582.namprd13.prod.outlook.com> <BYAPR05MB502933857FE0AFBA3390734DC7E40@BYAPR05MB5029.namprd05.prod.outlook.com> <MN2PR13MB3582B880C792E0519A3A91C385E40@MN2PR13MB3582.namprd13.prod.outlook.com> <BYAPR05MB5029581D97C82FA968601CCDC7E70@BYAPR05MB5029.namprd05.prod.outlook.com> <MN2PR13MB35826741E00B40BBFE12616085E70@MN2PR13MB3582.namprd13.prod.outlook.com> <4F580631-0E2D-4311-9EDC-E25A4862DD84@juniper.net> <BYAPR05MB5029D7B984EB0506C7773E63C7E20@BYAPR05MB5029.namprd05.prod.outlook.com> <CAOj+MMH-0qBkaroKJEdtjM1-7-ZjOY1mWBkS7hLo8FOC_5A+Og@mail.gmail.com> <BYAPR05MB50295A1AC3FB482F39249D0AC7E20@BYAPR05MB5029.namprd05.prod.outlook.com> <MN2PR13MB3582DDE034FA9E1C1D4970CD85E20@MN2PR13MB3582.namprd13.prod.outlook.com> <CAOj+MMEQC8Cv4m7DzG3jaqATaTTNSW7vReVHh5Zt8oTsH4Cf4g@mail.gmail.com> <MN2PR13MB358275094B0F91879189131685E20@MN2PR13MB3582.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB358275094B0F91879189131685E20@MN2PR13MB3582.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.239.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 58f8e627-7647-4698-16d2-08d6faa5cf06
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR05MB4235;
x-ms-traffictypediagnostic: DM6PR05MB4235:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <DM6PR05MB4235D255895EF30887A85EA5AAFD0@DM6PR05MB4235.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-forefront-prvs: 008184426E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(396003)(39860400002)(346002)(199004)(189003)(606006)(30864003)(66476007)(66946007)(6916009)(6512007)(5660300002)(966005)(66556008)(33656002)(36756003)(91956017)(73956011)(99286004)(66574012)(76116006)(5024004)(256004)(76176011)(14444005)(66446008)(26005)(3846002)(446003)(486006)(478600001)(11346002)(6436002)(102836004)(6116002)(6486002)(7736002)(64756008)(14454004)(81166006)(6506007)(81156014)(186003)(8936002)(86362001)(5070765005)(8676002)(476003)(53546011)(71200400001)(54896002)(2906002)(316002)(53936002)(53946003)(4326008)(25786009)(6246003)(66066001)(6306002)(68736007)(71190400001)(54906003)(236005)(229853002)(2616005)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4235; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: /4TReLPqfm87iXNx+aQwA+i7psvFLYRmYw+AT54wxPn00H9OYskGkdDHqbn3HvJPlBfFO49U1ca3sHu2mCroBG5rQ3yN5n/iuSsFucOvd2CvpGZCrjBEBLg/n0RP4ECwEM+LG+l+r968fLLfST2IPY7Q1LiT9DO6TnOgLcSoQS8V4QUgP62xjEqNSRDPuyQul8Zv9Bd0Qtx5jsgjgiaVpSeYdjLwMFbfjQR5p03F6UxAPPDD3qnYvAzM2b6SKSWDIT3evk5wEBrDvp0cH4xJAt5NST411BL9Mt/JNVGTwdawh/yXhPhOULQuNI1O3rFAH6Y9W6RW6nx8FSSMtUWtaIyVGaU5i2spcy0LYirb9iDT7MUJktdn/EJ3Qx2/SwD613rDAbLbzP7k8Vbv7fSafmxOlfL9V3+BsNZA6PP5w8U=
Content-Type: multipart/alternative; boundary="_000_1BB37B3A67A64DBDB774017F6AE41B77junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 58f8e627-7647-4698-16d2-08d6faa5cf06
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 02:18:56.8584 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4235
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-27_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270025
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/QNvU9LmQk-5tKOzxjVCzeTdcKho>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 02:19:11 -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 <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>> wrote:

Robert,

You said:
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.

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 <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Wednesday, June 26, 2019 4:55 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Cc: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
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
> 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 <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>> wrote:
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).

<image001.png>


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 <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Sent: Wednesday, June 26, 2019 4:07 PM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

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 <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Robert Raszuk
Sent: Wednesday, June 26, 2019 2:32 PM
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; idr@ietf.org<mailto:idr@ietf.org>
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.

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 ?

[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=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> 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


Juniper Business Use Only
From: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
Sent: Wednesday, June 26, 2019 2:06 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
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:


   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://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=>;).


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 <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>> wrote:

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 <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Sent: Friday, June 21, 2019 8:14 AM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda,

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

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

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

Yours Irrespectively,

John


Juniper Internal
From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: Thursday, June 20, 2019 7:08 PM
To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

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

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

We can ask the Tunnel-Encap authors to confirm.

Linda

From: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Sent: Thursday, June 20, 2019 5:50 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

Linda,

From section 5 on the Tunnel Encapsulation Attribute draft:

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

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

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

Yours Irrespectively,

John


Juniper Internal
From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: Thursday, June 20, 2019 6:08 PM
To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

John,

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

From: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
<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%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

[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

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
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
Idr@ietf.org<mailto:Idr@ietf.org>
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
Idr@ietf.org<mailto:Idr@ietf.org>
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=