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

[John Scudder <[e-mail]>]

(Still as an individual contributor of course.)

On Jun 26, 2019, at 4:02 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> 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:


   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