Guessing and trying can work because if you try to SYN on port 4342, you’ll get a RST or ICMP port unreachable back. That is if it gets back to you.
Dino > On Nov 14, 2021, at 10:01 PM, Marc Portoles Comeras (mportole) > <[email protected]> wrote: > > 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
