|
Thanks Magnus, please see inline.
From: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx> Hi Alberto,
See below. The complete exchange for a subscription operation would be: 2) MS->xTR (Map-Notify) 3) xTR->MS (Map-Notify-Ack) It is true that 3) is not explicitly stated on the PubSub document today, but it is required to align with RFC9301. We should update the PubSub doc to explicitly mention
3). I believe that having 1)+2)+3) explicitly stated should address your concerns regarding
return routability check, what do you think? MW: So if the Map-Notify-Ack would be part of the subscription process, such that 3) has to happen successfully for the Map-server to actually install the subscription
in its state then it would work. But, I get the impression that the map-server will install the subscription already as 1) has been completely processed.
[AR] I believe we could do the following. We can update the text to specify that (1) the xTR must send this Map-Notify-Ack as part of the subscription procedure, and that (2) the MapServer should
treat the subscription as incomplete until the Map-Notify-Ack is received (and therefore no publication will be sent to the xTR on the meantime).
I base that on that there are no process or error notification that would tell the xTR that its subscription request has failed as the MAP-Notify-Ack never reach it.
[AR] Note that if the MapServer does not receive the Map-Notify-Ack it will retransmit the Map-Notify (following the guidance being discussed in the parallel thread). Also note that section 5
of PubSub already specifies that: If the subscription request fails, the Map-Server MUST send a Map-Reply to the originator of the Map-Request What I think should happen here is. If the xTR never talked to this MS. Then the signalling looks like this. 1) xTR->MS (Map-Request) 1.1 MS->xTR (Return routability challenge with token) 1.2 xTR (Return routability ACK (with token)) 2) MS->xTR (Map-Notify) 3) xTR->MS (Map-Notify-Ack) Then the MS can install the subscription when it sends 2), and 3) is only a transport level ack, that is really not needed, as the xTR I would expect to retransmit 1)
after a timeout not getting the answer. Note 1.1 and 1.2 only happens occasionally if it hasn’t been run for the given xTR ID + RLOC the last 15 min or so.
So if one does multiple Map-Requests with subscription it only happens once.
[AR] I think this is a solid suggestion. But I would love to first explore if we could achieve the same thing using current machinery. Kindly let me know what you think of my suggestions above
and if you think we could converge following that path. Cheers Magnus |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
