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

John Scudder <> Wed, 26 June 2019 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE3E912018A; Wed, 26 Jun 2019 15:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5m7Z1P_9wl-W; Wed, 26 Jun 2019 15:16:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33B10120493; Wed, 26 Jun 2019 15:16:46 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x5QMDi0C001459; Wed, 26 Jun 2019 15:16:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=JtFg3lhpy8RFrHQxLIxgQc5HG7pla3rs33Sbsqh+EzY=; b=AC/dKZ08Dy3iowA++7SquvkAWwMhoKRfF6eQNA0RdzTcVXsp/Aji/1vQkfm3M+wGBgd/ JAAffbh2Nz8LIKnZ57oJR9/wb/w5wBjmO7mWcxXNSG7LV2loH1+9fRNS+f5AoAb0nANn GtKnQu/hG8Wl6J1MiovlT0rbof9lDga/rf4YQHFdGcqSB6hARgUG1IP15Oyx2Owt87X1 Ixdcpm2u9N7nEqsazCdJeYjaJhhyHZ7X4u/8YpBpuEUhG2DaokRADSABD7VLmOnBPt6p +9ttWIoUUMQv1tXV5CbgeyfAn7yZoRlc3IfyAnfcj8fHfWcukoyNSJgPlWVHu8AiZc7g Cg==
Received: from ( []) by with ESMTP id 2tcgya015u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Jun 2019 15:16:43 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.13; Wed, 26 Jun 2019 22:16:40 +0000
Received: from ([fe80::1549:ffd0:8373:4593]) by ([fe80::1549:ffd0:8373:4593%3]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 22:16:40 +0000
From: John Scudder <>
To: Linda Dunbar <>
CC: John E Drake <>, Robert Raszuk <>, "" <>, "" <>
Thread-Topic: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
Date: Wed, 26 Jun 2019 22:16:40 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 118ba432-cdf4-4695-c9f6-08d6fa83f6ca
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR05MB5468;
x-ms-traffictypediagnostic: DM6PR05MB5468:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00808B16F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(366004)(376002)(136003)(39860400002)(189003)(199004)(14444005)(6116002)(6486002)(73956011)(66556008)(66476007)(54906003)(36756003)(86362001)(68736007)(64756008)(6916009)(7736002)(305945005)(6512007)(66946007)(3846002)(66066001)(8676002)(91956017)(76176011)(99286004)(5660300002)(2616005)(2906002)(6246003)(25786009)(316002)(26005)(71200400001)(478600001)(76116006)(66446008)(53546011)(4326008)(81166006)(6506007)(53936002)(6436002)(8936002)(14454004)(33656002)(229853002)(446003)(476003)(11346002)(256004)(186003)(71190400001)(486006)(102836004)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5468;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MBAsLNFSBc8gm+xtLksAgzJ795lM5NIK7juQB8oaDxoKZrnuE5wDEEtjlV24lZmQ/gqK3XYy5KYiPqaNrT+MMQA04ob8at/KZ1MRH532lU/mttm/DOBCJUyhWZ47Cwk0jmS1I4nFl6FEF9K3tdl0DoFX8aXSm6GdkHnmlp1/U/6w05+tJyf8aiEzQepHO6RViwcWW3SdmdYzYBnF9u9Do65e9YuUlopsKh/vOuKeYwXdWf8ALjRJskUd3yE5zn+/kQvpdpBOpfqRk7B2zv+wbJQBsxNEMF1jcseR1bacaAQwxIGHFgP+aoqY8uBixxkB+fFC74PJK3BLaz5zuQV+nFuJuJRioOygBqw660GeUFyQzeLlaFLoOWYOyAEfCIeW7ifoxvI57bVcKfjGvNrM8s1FJWeC7EQBiO2zkaeMS0Q=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 118ba432-cdf4-4695-c9f6-08d6fa83f6ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 22:16:40.5749 (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-Transport-CrossTenantHeadersStamped: DM6PR05MB5468
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-26_12:, , 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=562 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260254
Archived-At: <>
Subject: Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Jun 2019 22:16:49 -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 <> 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).
> <image002.png>
> 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.
> 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”

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.