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