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

[Robert Raszuk <[e-mail]>]

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.


I can think of even more basic example .. when UPDATE crosses EBGP boundary
between N number of ASes. Next hop field will be rewritten while tunnel
endpoint will stay. For example for the purpose of providing end to end
transport any inter-as application :) .












On Thu, Jun 27, 2019 at 1:23 AM John Scudder <[e-mail]> wrote:

> (Still as an individual contributor of course.)
>
> On Jun 26, 2019, at 4:02 PM, Linda Dunbar <[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
>