I would incorporate this proposal in the draft. For now, in the current implementation, the ETRs are just "guessing and trying". As you say there is nothing in the Map-Notify telling the ETR if the MS can support the TCP connection. This signaling scheme would clear this part and remove this guesswork on the ETR.
Should we allow the Map-Server to set the RT bit even if the ETR has not requested it? Marc On 11/12/21, 1:53 PM, "lisp on behalf of Dino Farinacci" <[email protected] on behalf of [email protected]> wrote: Regarding the Luigi comment, I didn't understand Marc's response. Simply getting a Map-Notify doesn't tell the ETR if it should try a opening a TCP connection to the Map-Server. I would suggest this simple signalling scheme: (1) Since we have bits in the Map-Register header that the ETR can set. It sets a new "RT" bit to indicate to the Map-Server that it wants to use TCP. (2) If the Map-Server sends a Map-Notify (with the "RT" bit set, ie. copied from the Map-Register), then the ETR knows the Map-Server is listening on TCP port 4342 and will accept TCP connections. (3) If the Map-Server does not support RT, it sets the "RT" bit to zero. Which is its default setting because either an new implementation doesn't want to (so it clears the bit in the Map-Notify) or an old implementation doesn't know anything about the bit so it would default to 0. Comments? Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
