Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-pubsub-10

[Magnus Westerlund <[e-mail]>]

Hi Alberto,

See below.

The complete exchange for a subscription operation would be:

1) xTR->MS (Map-Request)
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