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 <[email protected]> wrote: > (Still as an individual contributor of course.) > > On Jun 26, 2019, at 4:02 PM, Linda Dunbar <[email protected]> > 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 >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
