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

["Alberto Rodriguez-Natal (natal)" <[e-mail]>]

Hi Magnus,

Thanks again, please see inline.

Alberto

From: Magnus Westerlund <[e-mail]>
Date: Monday, January 30, 2023 at 9:46 AM
To: Alberto Rodriguez-Natal (natal) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
Hi Alberto,

I think the below maybe works, but I like to point out that the Map-Server per the below is likely a larger DDoS traffic reflector than if you require a one-to-one exchange where each subscription request only results in a single response message. Using Map-Notify and requiring Ack will result in that at least 3 Map-Notifies are being sent.

[AR] Right, but this is required if we want to align with RFC9301, afaik.

I am also worried about the state uncertainty here. Because if the client sends Map-Notify-Ack on a Map-Notify it will think the subscription has succeeded, but if that ACK is lost and the MapServer has used up all retransmission it will silently remove the requested subscription. Is that not an issue?

[AR] I’ve been thinking about this as well. Maybe some middle ground, assuming that xTRs can be authenticated to some extend as being discussed in the other email, could be as follows. Rather than wait for the Map-Notify-Ack to mark the subscription state as completed, we still mark the subscription as complete as soon as the Map-Notify is sent. We still wait for the Map-Notify-Ack to be received, and if we exhaust all the retransmissions without receiving it, we don’t remove the subscription, we keep it as unacknowledged. However, we only allow the xTR to have a single unacknowledged subscription, subsequent subscription requests from the same xTR will be denied (i.e. Map-Reply returned) until the xTR is able to properly subscribe and acknowledge the previous one. Maybe this could work?

Cheers

Magnus


From: Alberto Rodriguez-Natal (natal) <[e-mail]>
Date: Friday, 27 January 2023 at 23:42
To: Magnus Westerlund <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
Thanks Magnus, please see inline.

From: Magnus Westerlund <[e-mail]>
Date: Friday, January 27, 2023 at 2:26 PM
To: Alberto Rodriguez-Natal (natal) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
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.

[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