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

Linda Dunbar <> Wed, 26 June 2019 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A23A5120169; Wed, 26 Jun 2019 16:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dE71v0g_hMoK; Wed, 26 Jun 2019 16:02:09 -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 2758612006B; Wed, 26 Jun 2019 16:02:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WL9MTPAZW52dC/kwx4qqCJgQVSOQp17ERWkIpDuIdDs=; b=QfBAVcgzetngY4CzoUW/Yx6iSojpozTbkgFD/Z/6gK74EPB3WnW8YtxashWeITThbFvtJ4aTRNIwgCaOnvH1lWTOu7SPeTO1ts1BsMk0qgQYK0XJ/GHi4LfatgB9Fr7qdGjLjFGqKv6dikxUgxx2eTBzcFTaUFVjEup/tJj5BIA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.13; Wed, 26 Jun 2019 23:02:06 +0000
Received: from ([fe80::a8cd:e9ef:5219:67ea]) by ([fe80::a8cd:e9ef:5219:67ea%6]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 23:02:06 +0000
From: Linda Dunbar <>
To: John Scudder <>
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 23:02:06 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f64a71ab-34fa-4f0f-1872-08d6fa8a4f8a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR13MB3424;
x-ms-traffictypediagnostic: MN2PR13MB3424:
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)(376002)(136003)(366004)(39850400004)(189003)(199004)(13464003)(6916009)(9686003)(54906003)(14444005)(256004)(476003)(6116002)(86362001)(5024004)(486006)(71200400001)(3846002)(71190400001)(446003)(55016002)(81166006)(8676002)(7736002)(4326008)(305945005)(2906002)(99286004)(8936002)(25786009)(11346002)(66066001)(6246003)(68736007)(81156014)(33656002)(6506007)(1941001)(73956011)(66476007)(66446008)(66556008)(66946007)(102836004)(64756008)(76176011)(229853002)(478600001)(52536014)(316002)(14454004)(966005)(5660300002)(74316002)(30864003)(44832011)(6436002)(26005)(7696005)(53936002)(76116006)(186003)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB3424;; 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: sVUZyimSMh+7kvwt0zT8hzAW2WJ11x2oURmlC6unr6smt26lTiiCnxgOeeWRoscgv0yhUDcUb7hv8AasETVtL2LDCMVxutZz4WP8TyuBIApJ//yTgUOTnB11RYbPKahZOqUhDRocmdc8M75x11AYhMiql2B9LfmJG4MgPDsUDzf/ddcHS40FDecOYlAnqqXb4FPnzHtp739F3fASpJx9swTH1uvSKkGlF+aP2VjRJbSO5MUTFd+WeewePCZlDDX257jN0AE3d7px+9SHoXMmkCY9ccK+7gnykiVUf/9HxiDsHWCVLPjo1WT2XzQdyzskUmQyFaSdg4b6WZtC4voWj4JYmPVfOaSxKR78rwDe9LK0Wm67HAS//ztaGrsj6PbmlvaBXjRJOQgmiPmdRuyW5SB8hZe8uY4+jxHQZebvoPM=
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB358203E404B3A94C7D3F15AA85E20MN2PR13MB3582namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f64a71ab-34fa-4f0f-1872-08d6fa8a4f8a
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 23:02:06.3846 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3424
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 23:02:12 -0000


Thank you very much for the explanation.

More questions are inserted below:

-----Original Message-----

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

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

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

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