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

John Scudder <> Wed, 26 June 2019 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9466E120692; Wed, 26 Jun 2019 16:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, 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 v08f2Xq5dXhi; Wed, 26 Jun 2019 16:23:49 -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 F13C812067D; Wed, 26 Jun 2019 16:23:48 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x5QNNjCU030015; Wed, 26 Jun 2019 16:23:45 -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 : mime-version; s=PPS1017; bh=TRwzzlo3SKDuU3LU5W78begJSwWkGZosZIaUxmSmNNk=; b=yymtediU5DqBMN5AwGX/sdYyehaA/NMdVkRbox4Rp3n+ONByqaU/B2aAz+/owOrPFzwk ZWFxL9or/K7izCCxgzy/k/JlBb8q0ewcQC5bP4ZQwzIVzfbh6L/VZZAv8raZ4L+D4M90 Tc8sZ8OSGbKXX2G8MXtmn9HKf/6Cgvu9aeOx/99tzXZczHT8CJOkL9kbZ0AeCm9omNkM VjEHQgqX3pRfwnWBWZXANA6quKzNch9iMYI64cYSk26JbiA7i4dGQAzyQOrf7t3Mzfqj kj2kilbq2eRusuoOjycRIbrOYVhIt3YesunfQ0q7xjNccdEqbUdraOS7qUpo3ufA91vg rQ==
Received: from ( []) by with ESMTP id 2tce16gdx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Jun 2019 16:23:45 -0700
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:23:42 +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 23:23:42 +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 23:23:42 +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: ca302efe-b3df-4373-8312-08d6fa8d5432
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:DM6PR05MB4715;
x-ms-traffictypediagnostic: DM6PR05MB4715:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 00808B16F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(136003)(376002)(396003)(199004)(189003)(5660300002)(6246003)(36756003)(236005)(7736002)(66946007)(73956011)(53936002)(66446008)(66556008)(76116006)(64756008)(14454004)(2616005)(6916009)(6436002)(11346002)(5024004)(14444005)(256004)(68736007)(66066001)(66574012)(91956017)(66476007)(6486002)(446003)(8676002)(476003)(81156014)(81166006)(8936002)(486006)(2906002)(99286004)(33656002)(478600001)(186003)(3846002)(6116002)(26005)(53546011)(102836004)(6506007)(86362001)(229853002)(6512007)(316002)(54896002)(54906003)(4326008)(76176011)(71190400001)(71200400001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4715;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: reGva7AnH7YYYlrFv9w9mUlxFx4cfOVFBBV5IVvCnXrh2fJvsZNPxqIjA5TMWv/DhXBIc3ia+LuaUjAiqlqevKPV+gV4ZExdnNZm4dKC4SY9YGuhVzRgn8B6bENxz/1AAIuP+tlNH06cqHYkB/Yn+G8eagtQSuDXKE66J1JW8YjcVaIUbfde+K+ilt/+/oljNGoWKIBFYfRCzLasGaNq/fZI/U7Hf4YfpMOuQnGwzjdoiImz4KjjjXCGGUC1xwzubruX5pziTEH334RPRBO5+3LQzMTHBeQ4IB2CyxSHgCQfSHUvoQ7lHhuFnFTLub4tJFAtPgM7ZFbhkQZ12/ZjTUp4osHYX7ziHSFLTfauhcrLdt/rbUUFQTROA8bsIKLGdCsl3isWW8xzWpop3lh8rav8zYzZYKxsft5zTqMoBss=
Content-Type: multipart/alternative; boundary="_000_D4DB28DDD3BD4F5B95B4D92BE6EEB584junipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ca302efe-b3df-4373-8312-08d6fa8d5432
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 23:23:42.7943 (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: DM6PR05MB4715
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-26_13:, , 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=400 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260269
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:23:58 -0000

(Still as an individual contributor of course.)

On Jun 26, 2019, at 4:02 PM, Linda Dunbar <<>> 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.

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.
[Linda] Isn’t the Source Address of the UPDATE message same as the originating node of the UPDATE message?

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:

      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.