PO in Sprint planning

One of the questions that is answered in Sprint Planning is "How will the work needed to deliver the Increment be achieved?". Different teams will answer this in different ways, but it's not inconceivable that a team will choose to become to decompose at least a portion of the Sprint Backlog into more detailed units of work and organizing this work into the Sprint Backlog.

I don't think it's a concern if the Product Owner is asking questions about the work. One of the responsibilities of the Product Owner is to maximize the value delivered. The Product Owner is also responsible for helping the Development Team make trade-offs. However, there is a fine line between making informed decisions on trade-offs and putting pressure on the team to get more done than they feel comfortable with or encouraging the team to cut corners and reduce quality or introduce unnecessary technical debt.

Please show him this statement from the Scrum guide:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality - Scrum Guide

And that as a Scrum master your job is to uphold the rules of Scrum. I also wrote an article about the "interfering product owner" and how it impacts the productivity and negatively affects the team morale. The idea of letting the team fail and realize the improvements is more important than imposing ideas of how to do things. As a Scrum Master I often find technical solutions that I believe are better options. But the solution that the team is comfortable with, wants to invest on and is excited about is key for team performance. 

The Product owner of course can suggest his choice of technologies and techniques based on the cost perspective but never impose them. When it comes to how to turn the PBI into a potentially releasable functionality the team's decision has to be respected.

I suggest to express your thoughts in a one on one session over a coffee or in an informal setting rather than in front of the entire team. We all know that we are defensive in presence of audience. 

Also if he is really interested in actively participating in the development efforts, the scrum guide does not restrict a PO from being part of the development team. But it is recommended. Here are my 2 main reasons:

• It may create conflict of interest
• It will drag down your output as a developer

And when he is part of the team the decision should still be from a team consensus. 

We got a new PO a couple of months back. He has understood the system fine and gels well too. However in a recent planning meeting, when we started discussing the stories one by one, he was questioning too much on how the technical aspect of them will be achieved and was comparing if we can leverage any of the existing stuff or in short if we can reduce the pointers. I just need to know what all a PO can do or cannot do in the planning meeting.

Planning is very late in the day to start discussing these matters, and increases risk to the Sprint, which has already started.

The Scrum Guide says: "The Development Team is responsible for all estimates", and "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog." Suggest to the Product Owner that raising any concerns during refinement would be more timely, and would help to mitigate risk and to maximize value.

I'm going to pull a couple of things from the Scrum Guide.  While @Uma-Venkata Ratna-Kumar Lekkala is correct with the quote he chose, I also believe that these are important to this conversation. All of these come from the section that describes Sprint Planning (emphasis added by me).

Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

The entire Scrum Team collaborates on understanding the work of the Sprint.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

I do not see any problem with the Product Owner asking the kind of questions you mentioned.  I do agree with @Ian Mitchell that those questions would be more useful is asked during refinement of the Product Backlog.  But they are valid questions regardless.  @Thomas Owens is correct that the Product Owner is responsible for ensuring the Development Team is providing the most value possible.  Sometimes reusing rather than building is more valuable to the organization and end user.