|
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. 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. 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.
Cheers Magnus |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
