But why gen a new id if someone passes you an id? Just use the supplied id in the called srvc.
This is certainly disputable territory, but the main motivation is that depending on service architecture, a single incoming request can balloon out into a full tree of backend requests because requests can map 1:N between any two components. Assigning every request in every component a unique ID allows any particular request to be isolated, while still allowing the any subsection of the tree to be viewed all at once.
Visually, this might look something like this:
Component 1 Component 2 Component 3
+----------------------+----------------------+----------------------+
* Request ID 1 ------- * Request ID 1-a ----- * Request ID 1-a-i
| \ --- * Request ID 1-a-ii
| ----- * Request ID 1-b
| ----- * Request ID 1-c ----- * Request ID 1-c-i
| \ --- * Request ID 1-c-ii
\ ----- * Request ID 1-d ----- * Request ID 1-d-i
| --- * Request ID 1-d-ii
\ --- * Request ID 1-d-iii
* Request ID 2
I could isolate just 1-a-i to view a single request to component 3, 1-a to view 1-a* in isolation, or use 1 to see everything.
A real world example of this is app.json, where a build service orchestrates many calls back to the main Heroku API in order to fulfill a single request (i.e. create the app, add config vars, provision add-ons, ...).
Another good reason is the possibility of a sociopathic client that always sends in the same request ID, thus preventing an operator from being able to readily inspect a single request.